You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by Steve Vinoski <vi...@iona.com> on 2006/09/05 22:04:37 UTC
maven
I'd like to "mavenize" the Qpid build (specifically with Maven 2, of
course). We have more than a few dependencies, such as log4j, a bunch
of jakarta commons stuff, some mina stuff, saxon, and xmlbeans, and
maven could help manage all that and any future dependencies we
create, such as for persistence. But maven brings other major
benefits too, such as single commands to set up Eclipse or IntelliJ
workspaces, commands to measure code coverage, commands to run code
style checkers, etc. I also think the standard maven directory
structure helps enforce subproject unit testing, as the tests and the
sources sit in peer directories under each subproject.
Now would be a good time to do this, obviously, given the code moving
into the incubator. Unless everyone hates the idea, I'll keep working
on it in my private workspace and try to have it ready by the end of
the week. Obviously, if anyone has any major concerns, please voice
them here.
thanks,
--steve
Re: maven
Posted by ma...@jpmorgan.com.
As we've just finished the build system re-org recently (and are still
finding small problems i.e. if you build on a windows machine the
manifests are not ok on Linux) I'd like to add some weight to a delay in
any maven-isation for a while please.
Each time I do a build (more or less) I'm finding small bugs in the
scripts/jars/code and it does present a reall problem for users of QPID at
the moment.
I'd certainly like to propose that we're careful that any maven
introduction is isolated until complete and tested on all platforms, in
the interests of some stability.
Regards,
Marnie
JPMorgan Chase
BLAZE (QPID) Integration Developer
https://confluence.uk.jpmorgan.com/confluence/display/IBTAMQ/Blaze
Steve Vinoski <vi...@iona.com>
05/09/2006 22:16
Please respond to qpid-dev
To: qpid-dev@incubator.apache.org, dev@etp.108.redhat.com
cc:
Subject: Re: maven
Will do.
--steve
On Sep 5, 2006, at 5:08 PM, Carl Trieloff wrote:
>
> Steve,
>
> can you maybe write a mail on any implications you see on the
> current code and structure. This would help me understand
> what we are in for if we got general agreement that this is what we
> should do. I know some had reservations previously but
> don't recall what they where.
>
> Carl.
>
>
> Steve Vinoski wrote:
>> Hi Carl, I'm happy to do it whenever the group feels it would be
>> best, but I'd rather not wait too long after it hits the
>> incubator, because the longer we wait, the more difficult it gets.
>>
>> So far I haven't found anything too difficult. As Alan said, the
>> existing directory structure isn't too far off what maven prefers,
>> and thus so far it seems to be a matter of properly identifying
>> dependencies and using a maven plugin for the XSLT code generation
>> steps.
>>
>> --steve
>>
>> On Sep 5, 2006, at 4:37 PM, Carl Trieloff wrote:
>>
>>>
>>> Steve,
>>>
>>> if we decide to add, go to.. maven builds do you mind if we do
>>> that post the code move to
>>> Apache. We still have some work to do to get the code into it's
>>> new home and I am scared that
>>> this might complicate this process. It might not, but I would
>>> prefer to get the code move
>>> behind us before introducing this.
>>>
>>> Carl.
>>>
>>>
>>> Alan Conway wrote:
>>>> +1 as long as I don't have to do it ;)
>>>>
>>>> I haven't used maven a lot but from the little I've used it it
>>>> seems to
>>>> eliminate a lot of the repetative junk that gets re-hashed on every
>>>> project.
>>>> The existing directory structure is very close to the maven
>>>> standard so
>>>> I don't see any big problems in the reorg.
>>>> On Tue, 2006-09-05 at 16:04 -0400, Steve Vinoski wrote:
>>>>
>>>>> I'd like to "mavenize" the Qpid build (specifically with Maven
>>>>> 2, of course). We have more than a few dependencies, such as
>>>>> log4j, a bunch of jakarta commons stuff, some mina stuff,
>>>>> saxon, and xmlbeans, and maven could help manage all that and
>>>>> any future dependencies we create, such as for persistence.
>>>>> But maven brings other major benefits too, such as single
>>>>> commands to set up Eclipse or IntelliJ workspaces, commands to
>>>>> measure code coverage, commands to run code style checkers,
>>>>> etc. I also think the standard maven directory structure helps
>>>>> enforce subproject unit testing, as the tests and the sources
>>>>> sit in peer directories under each subproject.
>>>>>
>>>>> Now would be a good time to do this, obviously, given the code
>>>>> moving into the incubator. Unless everyone hates the idea,
>>>>> I'll keep working on it in my private workspace and try to
>>>>> have it ready by the end of the week. Obviously, if anyone has
>>>>> any major concerns, please voice them here.
>>>>>
>>>>> thanks,
>>>>> --steve
>>>>>
>>>>
>>>>
>>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@etp.108.redhat.com
> For additional commands, e-mail: dev-help@etp.108.redhat.com
>
This communication is for informational purposes only. It is not intended as an offer or solicitation for the purchase or sale of any financial instrument or as an official confirmation of any transaction. All market prices, data and other information are not warranted as to completeness or accuracy and are subject to change without notice. Any comments or statements made herein do not necessarily reflect those of JPMorgan Chase & Co., its subsidiaries and affiliates.
This transmission may contain information that is privileged, confidential, legally privileged, and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is STRICTLY PROHIBITED. Although this transmission and any attachments are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by JPMorgan Chase & Co., its subsidiaries and affiliates, as applicable, for any loss or damage arising in any way from its use. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format. Thank you.
Re: maven
Posted by Steve Vinoski <vi...@iona.com>.
Will do.
--steve
On Sep 5, 2006, at 5:08 PM, Carl Trieloff wrote:
>
> Steve,
>
> can you maybe write a mail on any implications you see on the
> current code and structure. This would help me understand
> what we are in for if we got general agreement that this is what we
> should do. I know some had reservations previously but
> don't recall what they where.
>
> Carl.
>
>
> Steve Vinoski wrote:
>> Hi Carl, I'm happy to do it whenever the group feels it would be
>> best, but I'd rather not wait too long after it hits the
>> incubator, because the longer we wait, the more difficult it gets.
>>
>> So far I haven't found anything too difficult. As Alan said, the
>> existing directory structure isn't too far off what maven prefers,
>> and thus so far it seems to be a matter of properly identifying
>> dependencies and using a maven plugin for the XSLT code generation
>> steps.
>>
>> --steve
>>
>> On Sep 5, 2006, at 4:37 PM, Carl Trieloff wrote:
>>
>>>
>>> Steve,
>>>
>>> if we decide to add, go to.. maven builds do you mind if we do
>>> that post the code move to
>>> Apache. We still have some work to do to get the code into it's
>>> new home and I am scared that
>>> this might complicate this process. It might not, but I would
>>> prefer to get the code move
>>> behind us before introducing this.
>>>
>>> Carl.
>>>
>>>
>>> Alan Conway wrote:
>>>> +1 as long as I don't have to do it ;)
>>>>
>>>> I haven't used maven a lot but from the little I've used it it
>>>> seems to
>>>> eliminate a lot of the repetative junk that gets re-hashed on every
>>>> project.
>>>> The existing directory structure is very close to the maven
>>>> standard so
>>>> I don't see any big problems in the reorg.
>>>> On Tue, 2006-09-05 at 16:04 -0400, Steve Vinoski wrote:
>>>>
>>>>> I'd like to "mavenize" the Qpid build (specifically with Maven
>>>>> 2, of course). We have more than a few dependencies, such as
>>>>> log4j, a bunch of jakarta commons stuff, some mina stuff,
>>>>> saxon, and xmlbeans, and maven could help manage all that and
>>>>> any future dependencies we create, such as for persistence.
>>>>> But maven brings other major benefits too, such as single
>>>>> commands to set up Eclipse or IntelliJ workspaces, commands to
>>>>> measure code coverage, commands to run code style checkers,
>>>>> etc. I also think the standard maven directory structure helps
>>>>> enforce subproject unit testing, as the tests and the sources
>>>>> sit in peer directories under each subproject.
>>>>>
>>>>> Now would be a good time to do this, obviously, given the code
>>>>> moving into the incubator. Unless everyone hates the idea,
>>>>> I'll keep working on it in my private workspace and try to
>>>>> have it ready by the end of the week. Obviously, if anyone has
>>>>> any major concerns, please voice them here.
>>>>>
>>>>> thanks,
>>>>> --steve
>>>>>
>>>>
>>>>
>>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@etp.108.redhat.com
> For additional commands, e-mail: dev-help@etp.108.redhat.com
>
Re: maven
Posted by Carl Trieloff <cc...@redhat.com>.
Steve,
can you maybe write a mail on any implications you see on the current
code and structure. This would help me understand
what we are in for if we got general agreement that this is what we
should do. I know some had reservations previously but
don't recall what they where.
Carl.
Steve Vinoski wrote:
> Hi Carl, I'm happy to do it whenever the group feels it would be best,
> but I'd rather not wait too long after it hits the incubator, because
> the longer we wait, the more difficult it gets.
>
> So far I haven't found anything too difficult. As Alan said, the
> existing directory structure isn't too far off what maven prefers, and
> thus so far it seems to be a matter of properly identifying
> dependencies and using a maven plugin for the XSLT code generation steps.
>
> --steve
>
> On Sep 5, 2006, at 4:37 PM, Carl Trieloff wrote:
>
>>
>> Steve,
>>
>> if we decide to add, go to.. maven builds do you mind if we do that
>> post the code move to
>> Apache. We still have some work to do to get the code into it's new
>> home and I am scared that
>> this might complicate this process. It might not, but I would prefer
>> to get the code move
>> behind us before introducing this.
>>
>> Carl.
>>
>>
>> Alan Conway wrote:
>>> +1 as long as I don't have to do it ;)
>>>
>>> I haven't used maven a lot but from the little I've used it it seems to
>>> eliminate a lot of the repetative junk that gets re-hashed on every
>>> project.
>>> The existing directory structure is very close to the maven standard so
>>> I don't see any big problems in the reorg.
>>> On Tue, 2006-09-05 at 16:04 -0400, Steve Vinoski wrote:
>>>
>>>> I'd like to "mavenize" the Qpid build (specifically with Maven 2,
>>>> of course). We have more than a few dependencies, such as log4j, a
>>>> bunch of jakarta commons stuff, some mina stuff, saxon, and
>>>> xmlbeans, and maven could help manage all that and any future
>>>> dependencies we create, such as for persistence. But maven brings
>>>> other major benefits too, such as single commands to set up
>>>> Eclipse or IntelliJ workspaces, commands to measure code coverage,
>>>> commands to run code style checkers, etc. I also think the
>>>> standard maven directory structure helps enforce subproject unit
>>>> testing, as the tests and the sources sit in peer directories
>>>> under each subproject.
>>>>
>>>> Now would be a good time to do this, obviously, given the code
>>>> moving into the incubator. Unless everyone hates the idea, I'll
>>>> keep working on it in my private workspace and try to have it
>>>> ready by the end of the week. Obviously, if anyone has any major
>>>> concerns, please voice them here.
>>>>
>>>> thanks,
>>>> --steve
>>>>
>>>
>>>
>>
>
Re: maven
Posted by Steve Vinoski <vi...@iona.com>.
Hi Carl, I'm happy to do it whenever the group feels it would be
best, but I'd rather not wait too long after it hits the incubator,
because the longer we wait, the more difficult it gets.
So far I haven't found anything too difficult. As Alan said, the
existing directory structure isn't too far off what maven prefers,
and thus so far it seems to be a matter of properly identifying
dependencies and using a maven plugin for the XSLT code generation
steps.
--steve
On Sep 5, 2006, at 4:37 PM, Carl Trieloff wrote:
>
> Steve,
>
> if we decide to add, go to.. maven builds do you mind if we do that
> post the code move to
> Apache. We still have some work to do to get the code into it's new
> home and I am scared that
> this might complicate this process. It might not, but I would
> prefer to get the code move
> behind us before introducing this.
>
> Carl.
>
>
> Alan Conway wrote:
>> +1 as long as I don't have to do it ;)
>>
>> I haven't used maven a lot but from the little I've used it it
>> seems to
>> eliminate a lot of the repetative junk that gets re-hashed on every
>> project.
>> The existing directory structure is very close to the maven
>> standard so
>> I don't see any big problems in the reorg.
>> On Tue, 2006-09-05 at 16:04 -0400, Steve Vinoski wrote:
>>
>>> I'd like to "mavenize" the Qpid build (specifically with Maven 2,
>>> of course). We have more than a few dependencies, such as log4j,
>>> a bunch of jakarta commons stuff, some mina stuff, saxon, and
>>> xmlbeans, and maven could help manage all that and any future
>>> dependencies we create, such as for persistence. But maven
>>> brings other major benefits too, such as single commands to set
>>> up Eclipse or IntelliJ workspaces, commands to measure code
>>> coverage, commands to run code style checkers, etc. I also think
>>> the standard maven directory structure helps enforce subproject
>>> unit testing, as the tests and the sources sit in peer
>>> directories under each subproject.
>>>
>>> Now would be a good time to do this, obviously, given the code
>>> moving into the incubator. Unless everyone hates the idea, I'll
>>> keep working on it in my private workspace and try to have it
>>> ready by the end of the week. Obviously, if anyone has any major
>>> concerns, please voice them here.
>>>
>>> thanks,
>>> --steve
>>>
>>
>>
>
Re: maven
Posted by Carl Trieloff <cc...@redhat.com>.
Steve,
if we decide to add, go to.. maven builds do you mind if we do that post
the code move to
Apache. We still have some work to do to get the code into it's new home
and I am scared that
this might complicate this process. It might not, but I would prefer to
get the code move
behind us before introducing this.
Carl.
Alan Conway wrote:
> +1 as long as I don't have to do it ;)
>
> I haven't used maven a lot but from the little I've used it it seems to
> eliminate a lot of the repetative junk that gets re-hashed on every
> project.
>
> The existing directory structure is very close to the maven standard so
> I don't see any big problems in the reorg.
>
> On Tue, 2006-09-05 at 16:04 -0400, Steve Vinoski wrote:
>
>> I'd like to "mavenize" the Qpid build (specifically with Maven 2, of
>> course). We have more than a few dependencies, such as log4j, a bunch
>> of jakarta commons stuff, some mina stuff, saxon, and xmlbeans, and
>> maven could help manage all that and any future dependencies we
>> create, such as for persistence. But maven brings other major
>> benefits too, such as single commands to set up Eclipse or IntelliJ
>> workspaces, commands to measure code coverage, commands to run code
>> style checkers, etc. I also think the standard maven directory
>> structure helps enforce subproject unit testing, as the tests and the
>> sources sit in peer directories under each subproject.
>>
>> Now would be a good time to do this, obviously, given the code moving
>> into the incubator. Unless everyone hates the idea, I'll keep working
>> on it in my private workspace and try to have it ready by the end of
>> the week. Obviously, if anyone has any major concerns, please voice
>> them here.
>>
>> thanks,
>> --steve
>>
>
>
Re: maven
Posted by Alan Conway <ac...@redhat.com>.
+1 as long as I don't have to do it ;)
I haven't used maven a lot but from the little I've used it it seems to
eliminate a lot of the repetative junk that gets re-hashed on every
project.
The existing directory structure is very close to the maven standard so
I don't see any big problems in the reorg.
On Tue, 2006-09-05 at 16:04 -0400, Steve Vinoski wrote:
> I'd like to "mavenize" the Qpid build (specifically with Maven 2, of
> course). We have more than a few dependencies, such as log4j, a bunch
> of jakarta commons stuff, some mina stuff, saxon, and xmlbeans, and
> maven could help manage all that and any future dependencies we
> create, such as for persistence. But maven brings other major
> benefits too, such as single commands to set up Eclipse or IntelliJ
> workspaces, commands to measure code coverage, commands to run code
> style checkers, etc. I also think the standard maven directory
> structure helps enforce subproject unit testing, as the tests and the
> sources sit in peer directories under each subproject.
>
> Now would be a good time to do this, obviously, given the code moving
> into the incubator. Unless everyone hates the idea, I'll keep working
> on it in my private workspace and try to have it ready by the end of
> the week. Obviously, if anyone has any major concerns, please voice
> them here.
>
> thanks,
> --steve
Re: maven
Posted by Rajith Attapattu <ra...@gmail.com>.
+1 for maven as long as we have clear concise documentation about the goals.
Btw how can a user know what the current project goals are ?
Is there a replacement in mvn for maven -g ? (well maven -g sucks as it
prints a huge list)
-Rajith
On 9/6/06, Gordon Sim <gs...@redhat.com> wrote:
>
> Steve Vinoski wrote:
> > I'd like to "mavenize" the Qpid build (specifically with Maven 2, of
> > course). We have more than a few dependencies, such as log4j, a bunch of
> > jakarta commons stuff, some mina stuff, saxon, and xmlbeans, and maven
> > could help manage all that and any future dependencies we create, such
> > as for persistence. But maven brings other major benefits too, such as
> > single commands to set up Eclipse or IntelliJ workspaces, commands to
> > measure code coverage, commands to run code style checkers, etc. I also
> > think the standard maven directory structure helps enforce subproject
> > unit testing, as the tests and the sources sit in peer directories under
> > each subproject.
> >
> > Now would be a good time to do this, obviously, given the code moving
> > into the incubator. Unless everyone hates the idea, I'll keep working on
> > it in my private workspace and try to have it ready by the end of the
> > week. Obviously, if anyone has any major concerns, please voice them
> here.
>
> I'm _personally_ not a fan of maven. It has always seemed overly complex
> & rigid to me, very possibly because I haven't spent the time learning
> how to use it properly. The reason I haven't spent that time is that
> I've never been convinced of its benefits.
>
> For the dependencies, the jakarta commons stuff is the most messy. Mina
> so far has been built from subversion as we have been ahead of the
> published releases and changes to the mina version have resulted in the
> need to rework some of our code anyway. Saxon is only used as an xslt2
> engine for the code generation so I don't see it as a dependency that
> will require much management, I _think_ xmlbeans is only used in the
> not-really-maintained management module though that may be wrong and may
> change.
>
> Adding ant tasks to run various tools over code has never been something
> I felt was overly arduous. And as mentioned the current structure is
> more or less the same as maven would enforce (and I've never liked tools
> that enforce directory structures anyway!).
>
> Bottom line is however that I would be prepared to live with whatever
> the group at large feel is appropriate. It seems those in favour of
> maven are in the majority, so perhaps its time for me to accept the
> inevitable!
>
Re: maven
Posted by Gordon Sim <gs...@redhat.com>.
Steve Vinoski wrote:
> I'd like to "mavenize" the Qpid build (specifically with Maven 2, of
> course). We have more than a few dependencies, such as log4j, a bunch of
> jakarta commons stuff, some mina stuff, saxon, and xmlbeans, and maven
> could help manage all that and any future dependencies we create, such
> as for persistence. But maven brings other major benefits too, such as
> single commands to set up Eclipse or IntelliJ workspaces, commands to
> measure code coverage, commands to run code style checkers, etc. I also
> think the standard maven directory structure helps enforce subproject
> unit testing, as the tests and the sources sit in peer directories under
> each subproject.
>
> Now would be a good time to do this, obviously, given the code moving
> into the incubator. Unless everyone hates the idea, I'll keep working on
> it in my private workspace and try to have it ready by the end of the
> week. Obviously, if anyone has any major concerns, please voice them here.
I'm _personally_ not a fan of maven. It has always seemed overly complex
& rigid to me, very possibly because I haven't spent the time learning
how to use it properly. The reason I haven't spent that time is that
I've never been convinced of its benefits.
For the dependencies, the jakarta commons stuff is the most messy. Mina
so far has been built from subversion as we have been ahead of the
published releases and changes to the mina version have resulted in the
need to rework some of our code anyway. Saxon is only used as an xslt2
engine for the code generation so I don't see it as a dependency that
will require much management, I _think_ xmlbeans is only used in the
not-really-maintained management module though that may be wrong and may
change.
Adding ant tasks to run various tools over code has never been something
I felt was overly arduous. And as mentioned the current structure is
more or less the same as maven would enforce (and I've never liked tools
that enforce directory structures anyway!).
Bottom line is however that I would be prepared to live with whatever
the group at large feel is appropriate. It seems those in favour of
maven are in the majority, so perhaps its time for me to accept the
inevitable!
Re: maven
Posted by Carl Trieloff <cc...@redhat.com>.
duplicate, thought my mailed had trashed my previous send.
Carl Trieloff wrote:
> Steve Vinoski wrote:
>> Not to start a protracted Maven war, but the benefits of Maven are
>> many. In no particular order:
> (I would not classify my last mail as an anti Maven mail)
>>
>> 1. Using it shows us as good Apache community citizens, as many new
>> projects around here use it.
> Ant is also Apache
>
>> 2. Using the regular Maven directory structure enables new
>> contributors to easily get up to speed.
>> 3. It easily allows us to manage dependencies, which granted we
>> currently have few of (though more than I initially thought), but
>> that number will grow, for example as new persistence solutions are
>> introduced.
> Not for all our stuff today - issues around things like Mina
>> 4. It enables us to easily produce snapshots and releases into the
>> Apache repository so that other projects can be based on us.
>> 5. It gives us simple set up for Eclipse and IntelliJ workspaces.
>> 6. It gives us code coverage.
> Not true, PMD, CheckStyle, etc integrations give us this
>> 7. It gives us the ability to turn on code style checking at build
>> time, assuming we want that someday (it's definitely got my vote).
> Not a maven exclusive
>> 8. We can easily pick up Maven plugins and use them at will, without
>> having to write Ant targets or import specialized Ant task classes.
>> 9. It makes creating distributions dead easy.
>> 10. It's much faster and more scalable than Ant.
>>
>> I can come up with more good reasons if you like.
>>
>> Not to mention that the sooner we move to it, the less work it will
>> be. If we wait, the code base will grow and just make it that much
>> harder to move to a new build system and directory structure.
>>
>> IONA has a number of projects, both open source and company-internal,
>> using Maven, and it's been working great for all of them. Given my
>> long history and experience with software configuration management
>> and build systems, I am generally skeptical of tools like Maven that
>> come along and make lots of promises. However, my hat is definitely
>> off to the Maven guys, it's a great system that delivers the goods.
>
> I can point out that I introduced Maven to IONA, so yes I know the
> benefits of Maven and I like it a LOT. So Steve I don't see this mail
> as a war, just the practicalities of what I have to do to make the
> code donation and move the project to Apache. I would like to complete
> this
> process so that I can know the apache svn is correctly imported and we
> can create a baseline build and make sure all is good. If we go
> to Maven I want us to discuss the issues, and how we want it set up
> and make sure that works for all.
>
> For example, I want to see the impact on the dir structure and look if
> we want to make the C++ make structure match for example,want to know
> what we are going to do with Mina, etc... I don't think Maven is going
> to solve all the issues, and want us to make sure the ones that is
> does not we know how we are going to solve them.
>
> Regards
> Carl.
>
>
>>
>> More details will be forthcoming as I progress my Maven work for Qpid.
>>
>> --steve
>>
>> On Sep 7, 2006, at 5:40 PM, Carl Trieloff wrote:
>>
>>>
>>> Would like to park the maven discussion until Steve comes back with
>>> something that we can concretely
>>> discuss. My view is Maven does not help us any at this stage, and
>>> there are better uses of time right
>>> now on the code base, (but that is my view) and I might change it
>>> after Steve comes back with his
>>> research.
>>>
>>> Regards
>>> Carl.
>>>
>>> steven.x.shaw@jpmorgan.com wrote:
>>>> Could be wonderful. Maven makes alot of promises. I really like he
>>>> IDE file generation. Maven seem popular at Apache.
>>>>
>>>> I did spent a while trying to get Maven 2.0.2 and then 2.0.4
>>>> working to build Mina here at JPMC. It just wouldn't work. I
>>>> configured my http proxy. It couldn't download the
>>>> maven-compiler-plugin I think. At home it worked fine :). I figure
>>>> that I was having some kind of firewall issue but the error
>>>> messages leave alot to be desired! I ended up building mina-core
>>>> with a very short shell script...
>>>>
>>>> Steve.
>>>>
>>>> This communication is for informational purposes only. It is not
>>>> intended as an offer or solicitation for the purchase or sale of
>>>> any financial instrument or as an official confirmation of any
>>>> transaction. All market prices, data and other information are not
>>>> warranted as to completeness or accuracy and are subject to change
>>>> without notice. Any comments or statements made herein do not
>>>> necessarily reflect those of JPMorgan Chase & Co., its subsidiaries
>>>> and affiliates.
>>>>
>>>> This transmission may contain information that is privileged,
>>>> confidential, legally privileged, and/or exempt from disclosure
>>>> under applicable law. If you are not the intended recipient, you
>>>> are hereby notified that any disclosure, copying, distribution, or
>>>> use of the information contained herein (including any reliance
>>>> thereon) is STRICTLY PROHIBITED. Although this transmission and any
>>>> attachments are believed to be free of any virus or other defect
>>>> that might affect any computer system into which it is received and
>>>> opened, it is the responsibility of the recipient to ensure that it
>>>> is virus free and no responsibility is accepted by JPMorgan Chase &
>>>> Co., its subsidiaries and affiliates, as applicable, for any loss
>>>> or damage arising in any way from its use. If you received this
>>>> transmission in error, please immediately contact the sender and
>>>> destroy the material in its entirety, whether in electronic or hard
>>>> copy format. Thank you.
>>>>
>>>
>>>
>>
>
>
Re: maven
Posted by ma...@jpmorgan.com.
Thanks for that Steve.
I think we are yet to formalise a platform support list but it should
include solaris 8, linux (v ?), windows ....
Perhaps cygwin too.
Regards,
Marnie
Steve Vinoski <vi...@iona.com>
12/09/2006 15:40
Please respond to qpid-dev
To: qpid-dev@incubator.apache.org
cc:
Subject: Re: maven
On Sep 12, 2006, at 3:09 AM, marnie.mccormack@jpmorgan.com wrote:
> We certianly have awareness of tasks that need to be prioritised
> for the
> jms client. As soon as there's a project tracker/jira on Apache
> that we
> can use we can start there.
I think getting JIRA up as soon as possible could help in a number of
areas. I suspect that those of you who have been working on the code
for awhile could quickly add a bunch of to-do tasks to JIRA.
> On the maven front, I just want to (sorry but feel very strongly)
> state
> that any work on the build system must be isolated until complete &
> tested
> on all platforms. I cannot go back through build related pain :-)
I have no issue with that whatsoever, and is in fact part of the
reason I talked in another email thread about creating a branch, so
that we can all test the maven stuff on a variety of platforms before
deciding if and when to move to it. Having a working build system is
paramount.
However, what does "all platforms" mean? Are the platforms that must
be supported documented somewhere?
thanks,
--steve
>
> Regards,
> Marnie
>
>
>
>
>
>
> Steve Vinoski <vi...@iona.com>
> 08/09/2006 21:53
> Please respond to qpid-dev
>
> To: qpid-dev@incubator.apache.org
> cc:
> Subject: Re: maven
>
>
> Kim, questions (c) and (d) are good ones, making me wonder whether
> there is a list of to-do items somewhere that we can transfer into
> Qpid JIRA, assuming we get that set up soon? That way the group would
> get a much better idea of how much work there is to do, so we can
> better prioritize it.
>
> --steve
>
> On Sep 8, 2006, at 9:28 AM, Kim van der Riet wrote:
>
>> While the advantages of Maven seem clear, the question becomes:
>>
>> a) How much effort will it take to implement Maven at this stage?
>> b) What is the risk of disruption to the development process if there
>> are hiccups?
>>
>> If the answer to these questions is little effort, little risk,
>> then it
>> seems to make sense to go ahead and make the change - if someone is
>> willing to do so. If the change involves significant effort and/or
>> risk
>> of disruption, then I would also ask the following:
>>
>> c) Does Maven bring any immediate advantages to the project that
>> could
>> help it along?
>> d) Is the effort spent implementing Maven better spent elsewhere on
>> the
>> project right now? There are still many holes and fixes that are
>> urgently needed, and would it not be better at this juncture to
>> rather
>> concentrate on the "nuts and bolts" issues?
>> e) Is it wise to introduce another major system change at the same
>> time
>> that we switch our source from 108 to Apache?
>>
>> Given the general support for Maven and the advantages it brings,
>> this
>> is not a question of "if" but of "when". Lets consider whether
>> this is
>> in fact the best moment for such a change.
>>
>> Kim
>>
>> On Fri, 2006-09-08 at 08:59 -0400, Carl Trieloff wrote:
>>
>>> Steve,
>>>
>>> "You said Maven doesn't help us at this stage. In response gave 10
>>> good
>>> reasons why it does." - all I wanted
>>> was a window do get the code move done, thus should have said,
>>> adding
>>> maven now does not help ME in the
>>> code move. We all know the merits of maven. I am appreciative that
>>> you
>>> are willing to work out what the
>>> project will look like.
>>>
>>> Carl.
>
>
>
>
> This communication is for informational purposes only. It is not
> intended as an offer or solicitation for the purchase or sale of
> any financial instrument or as an official confirmation of any
> transaction. All market prices, data and other information are not
> warranted as to completeness or accuracy and are subject to change
> without notice. Any comments or statements made herein do not
> necessarily reflect those of JPMorgan Chase & Co., its subsidiaries
> and affiliates.
>
> This transmission may contain information that is privileged,
> confidential, legally privileged, and/or exempt from disclosure
> under applicable law. If you are not the intended recipient, you
> are hereby notified that any disclosure, copying, distribution, or
> use of the information contained herein (including any reliance
> thereon) is STRICTLY PROHIBITED. Although this transmission and any
> attachments are believed to be free of any virus or other defect
> that might affect any computer system into which it is received and
> opened, it is the responsibility of the recipient to ensure that it
> is virus free and no responsibility is accepted by JPMorgan Chase &
> Co., its subsidiaries and affiliates, as applicable, for any loss
> or damage arising in any way from its use. If you received this
> transmission in error, please immediately contact the sender and
> destroy the material in its entirety, whether in electronic or hard
> copy format. Thank you.
This communication is for informational purposes only. It is not intended as an offer or solicitation for the purchase or sale of any financial instrument or as an official confirmation of any transaction. All market prices, data and other information are not warranted as to completeness or accuracy and are subject to change without notice. Any comments or statements made herein do not necessarily reflect those of JPMorgan Chase & Co., its subsidiaries and affiliates.
This transmission may contain information that is privileged, confidential, legally privileged, and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is STRICTLY PROHIBITED. Although this transmission and any attachments are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by JPMorgan Chase & Co., its subsidiaries and affiliates, as applicable, for any loss or damage arising in any way from its use. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format. Thank you.
Re: maven
Posted by Steve Vinoski <vi...@iona.com>.
On Sep 12, 2006, at 3:09 AM, marnie.mccormack@jpmorgan.com wrote:
> We certianly have awareness of tasks that need to be prioritised
> for the
> jms client. As soon as there's a project tracker/jira on Apache
> that we
> can use we can start there.
I think getting JIRA up as soon as possible could help in a number of
areas. I suspect that those of you who have been working on the code
for awhile could quickly add a bunch of to-do tasks to JIRA.
> On the maven front, I just want to (sorry but feel very strongly)
> state
> that any work on the build system must be isolated until complete &
> tested
> on all platforms. I cannot go back through build related pain :-)
I have no issue with that whatsoever, and is in fact part of the
reason I talked in another email thread about creating a branch, so
that we can all test the maven stuff on a variety of platforms before
deciding if and when to move to it. Having a working build system is
paramount.
However, what does "all platforms" mean? Are the platforms that must
be supported documented somewhere?
thanks,
--steve
>
> Regards,
> Marnie
>
>
>
>
>
>
> Steve Vinoski <vi...@iona.com>
> 08/09/2006 21:53
> Please respond to qpid-dev
>
> To: qpid-dev@incubator.apache.org
> cc:
> Subject: Re: maven
>
>
> Kim, questions (c) and (d) are good ones, making me wonder whether
> there is a list of to-do items somewhere that we can transfer into
> Qpid JIRA, assuming we get that set up soon? That way the group would
> get a much better idea of how much work there is to do, so we can
> better prioritize it.
>
> --steve
>
> On Sep 8, 2006, at 9:28 AM, Kim van der Riet wrote:
>
>> While the advantages of Maven seem clear, the question becomes:
>>
>> a) How much effort will it take to implement Maven at this stage?
>> b) What is the risk of disruption to the development process if there
>> are hiccups?
>>
>> If the answer to these questions is little effort, little risk,
>> then it
>> seems to make sense to go ahead and make the change - if someone is
>> willing to do so. If the change involves significant effort and/or
>> risk
>> of disruption, then I would also ask the following:
>>
>> c) Does Maven bring any immediate advantages to the project that
>> could
>> help it along?
>> d) Is the effort spent implementing Maven better spent elsewhere on
>> the
>> project right now? There are still many holes and fixes that are
>> urgently needed, and would it not be better at this juncture to
>> rather
>> concentrate on the "nuts and bolts" issues?
>> e) Is it wise to introduce another major system change at the same
>> time
>> that we switch our source from 108 to Apache?
>>
>> Given the general support for Maven and the advantages it brings,
>> this
>> is not a question of "if" but of "when". Lets consider whether
>> this is
>> in fact the best moment for such a change.
>>
>> Kim
>>
>> On Fri, 2006-09-08 at 08:59 -0400, Carl Trieloff wrote:
>>
>>> Steve,
>>>
>>> "You said Maven doesn't help us at this stage. In response gave 10
>>> good
>>> reasons why it does." - all I wanted
>>> was a window do get the code move done, thus should have said,
>>> adding
>>> maven now does not help ME in the
>>> code move. We all know the merits of maven. I am appreciative that
>>> you
>>> are willing to work out what the
>>> project will look like.
>>>
>>> Carl.
>
>
>
>
> This communication is for informational purposes only. It is not
> intended as an offer or solicitation for the purchase or sale of
> any financial instrument or as an official confirmation of any
> transaction. All market prices, data and other information are not
> warranted as to completeness or accuracy and are subject to change
> without notice. Any comments or statements made herein do not
> necessarily reflect those of JPMorgan Chase & Co., its subsidiaries
> and affiliates.
>
> This transmission may contain information that is privileged,
> confidential, legally privileged, and/or exempt from disclosure
> under applicable law. If you are not the intended recipient, you
> are hereby notified that any disclosure, copying, distribution, or
> use of the information contained herein (including any reliance
> thereon) is STRICTLY PROHIBITED. Although this transmission and any
> attachments are believed to be free of any virus or other defect
> that might affect any computer system into which it is received and
> opened, it is the responsibility of the recipient to ensure that it
> is virus free and no responsibility is accepted by JPMorgan Chase &
> Co., its subsidiaries and affiliates, as applicable, for any loss
> or damage arising in any way from its use. If you received this
> transmission in error, please immediately contact the sender and
> destroy the material in its entirety, whether in electronic or hard
> copy format. Thank you.
Re: maven
Posted by ma...@jpmorgan.com.
We certianly have awareness of tasks that need to be prioritised for the
jms client. As soon as there's a project tracker/jira on Apache that we
can use we can start there.
On the maven front, I just want to (sorry but feel very strongly) state
that any work on the build system must be isolated until complete & tested
on all platforms. I cannot go back through build related pain :-)
Regards,
Marnie
Steve Vinoski <vi...@iona.com>
08/09/2006 21:53
Please respond to qpid-dev
To: qpid-dev@incubator.apache.org
cc:
Subject: Re: maven
Kim, questions (c) and (d) are good ones, making me wonder whether
there is a list of to-do items somewhere that we can transfer into
Qpid JIRA, assuming we get that set up soon? That way the group would
get a much better idea of how much work there is to do, so we can
better prioritize it.
--steve
On Sep 8, 2006, at 9:28 AM, Kim van der Riet wrote:
> While the advantages of Maven seem clear, the question becomes:
>
> a) How much effort will it take to implement Maven at this stage?
> b) What is the risk of disruption to the development process if there
> are hiccups?
>
> If the answer to these questions is little effort, little risk,
> then it
> seems to make sense to go ahead and make the change - if someone is
> willing to do so. If the change involves significant effort and/or
> risk
> of disruption, then I would also ask the following:
>
> c) Does Maven bring any immediate advantages to the project that could
> help it along?
> d) Is the effort spent implementing Maven better spent elsewhere on
> the
> project right now? There are still many holes and fixes that are
> urgently needed, and would it not be better at this juncture to rather
> concentrate on the "nuts and bolts" issues?
> e) Is it wise to introduce another major system change at the same
> time
> that we switch our source from 108 to Apache?
>
> Given the general support for Maven and the advantages it brings, this
> is not a question of "if" but of "when". Lets consider whether this is
> in fact the best moment for such a change.
>
> Kim
>
> On Fri, 2006-09-08 at 08:59 -0400, Carl Trieloff wrote:
>
>> Steve,
>>
>> "You said Maven doesn't help us at this stage. In response gave 10
>> good
>> reasons why it does." - all I wanted
>> was a window do get the code move done, thus should have said, adding
>> maven now does not help ME in the
>> code move. We all know the merits of maven. I am appreciative that
>> you
>> are willing to work out what the
>> project will look like.
>>
>> Carl.
This communication is for informational purposes only. It is not intended as an offer or solicitation for the purchase or sale of any financial instrument or as an official confirmation of any transaction. All market prices, data and other information are not warranted as to completeness or accuracy and are subject to change without notice. Any comments or statements made herein do not necessarily reflect those of JPMorgan Chase & Co., its subsidiaries and affiliates.
This transmission may contain information that is privileged, confidential, legally privileged, and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is STRICTLY PROHIBITED. Although this transmission and any attachments are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by JPMorgan Chase & Co., its subsidiaries and affiliates, as applicable, for any loss or damage arising in any way from its use. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format. Thank you.
Re: maven
Posted by Steve Vinoski <vi...@iona.com>.
Kim, questions (c) and (d) are good ones, making me wonder whether
there is a list of to-do items somewhere that we can transfer into
Qpid JIRA, assuming we get that set up soon? That way the group would
get a much better idea of how much work there is to do, so we can
better prioritize it.
--steve
On Sep 8, 2006, at 9:28 AM, Kim van der Riet wrote:
> While the advantages of Maven seem clear, the question becomes:
>
> a) How much effort will it take to implement Maven at this stage?
> b) What is the risk of disruption to the development process if there
> are hiccups?
>
> If the answer to these questions is little effort, little risk,
> then it
> seems to make sense to go ahead and make the change - if someone is
> willing to do so. If the change involves significant effort and/or
> risk
> of disruption, then I would also ask the following:
>
> c) Does Maven bring any immediate advantages to the project that could
> help it along?
> d) Is the effort spent implementing Maven better spent elsewhere on
> the
> project right now? There are still many holes and fixes that are
> urgently needed, and would it not be better at this juncture to rather
> concentrate on the "nuts and bolts" issues?
> e) Is it wise to introduce another major system change at the same
> time
> that we switch our source from 108 to Apache?
>
> Given the general support for Maven and the advantages it brings, this
> is not a question of "if" but of "when". Lets consider whether this is
> in fact the best moment for such a change.
>
> Kim
>
> On Fri, 2006-09-08 at 08:59 -0400, Carl Trieloff wrote:
>
>> Steve,
>>
>> "You said Maven doesn't help us at this stage. In response gave 10
>> good
>> reasons why it does." - all I wanted
>> was a window do get the code move done, thus should have said, adding
>> maven now does not help ME in the
>> code move. We all know the merits of maven. I am appreciative that
>> you
>> are willing to work out what the
>> project will look like.
>>
>> Carl.
Re: maven
Posted by Kim van der Riet <ki...@redhat.com>.
While the advantages of Maven seem clear, the question becomes:
a) How much effort will it take to implement Maven at this stage?
b) What is the risk of disruption to the development process if there
are hiccups?
If the answer to these questions is little effort, little risk, then it
seems to make sense to go ahead and make the change - if someone is
willing to do so. If the change involves significant effort and/or risk
of disruption, then I would also ask the following:
c) Does Maven bring any immediate advantages to the project that could
help it along?
d) Is the effort spent implementing Maven better spent elsewhere on the
project right now? There are still many holes and fixes that are
urgently needed, and would it not be better at this juncture to rather
concentrate on the "nuts and bolts" issues?
e) Is it wise to introduce another major system change at the same time
that we switch our source from 108 to Apache?
Given the general support for Maven and the advantages it brings, this
is not a question of "if" but of "when". Lets consider whether this is
in fact the best moment for such a change.
Kim
On Fri, 2006-09-08 at 08:59 -0400, Carl Trieloff wrote:
> Steve,
>
> "You said Maven doesn't help us at this stage. In response gave 10 good
> reasons why it does." - all I wanted
> was a window do get the code move done, thus should have said, adding
> maven now does not help ME in the
> code move. We all know the merits of maven. I am appreciative that you
> are willing to work out what the
> project will look like.
>
> Carl.
Re: maven
Posted by Carl Trieloff <cc...@redhat.com>.
Steve,
"You said Maven doesn't help us at this stage. In response gave 10 good
reasons why it does." - all I wanted
was a window do get the code move done, thus should have said, adding
maven now does not help ME in the
code move. We all know the merits of maven. I am appreciative that you
are willing to work out what the
project will look like.
Carl.
Re: maven
Posted by Steve Vinoski <vi...@iona.com>.
On Sep 7, 2006, at 8:36 PM, Carl Trieloff wrote:
> Steve Vinoski wrote:
>> Not to start a protracted Maven war, but the benefits of Maven are
>> many. In no particular order:
> (I would not classify my last mail as an anti Maven mail)
You said Maven doesn't help us at this stage. In response gave 10
good reasons why it does.
>>
>> 1. Using it shows us as good Apache community citizens, as many
>> new projects around here use it.
> Ant is also Apache
Yes, and if it were truly sufficient, I bet Apache wouldn't host
Maven as well.
>> 2. Using the regular Maven directory structure enables new
>> contributors to easily get up to speed.
>> 3. It easily allows us to manage dependencies, which granted we
>> currently have few of (though more than I initially thought), but
>> that number will grow, for example as new persistence solutions
>> are introduced.
> Not for all our stuff today - issues around things like Mina
Not a problem at all. The version of mina we use is currently checked
into svn, so populating your local m2 repository with a copy of it is
a single simple maven command. And given that it's Apache, we can
probably get their snapshot of what we use into the Apache m2
repository, if it's not already there. In fact, if they also use
Maven, getting it there would literally take them only a minute or two.
>> 4. It enables us to easily produce snapshots and releases into the
>> Apache repository so that other projects can be based on us.
>> 5. It gives us simple set up for Eclipse and IntelliJ workspaces.
>> 6. It gives us code coverage.
> Not true, PMD, CheckStyle, etc integrations give us this
And how does that differ in substance from what I said? Yes, I know
that such capabilities are delivered by plugins -- indeed, the fact
that plugins deliver such capabilities for maven is another plus, as
it means the system is highly flexible and extensible.
>> 7. It gives us the ability to turn on code style checking at build
>> time, assuming we want that someday (it's definitely got my vote).
> Not a maven exclusive
Again, not sure why you would even argue this. I never said it was an
exclusive. I would point out, though, that such things are generally
easier with maven than anything else I've seen.
>> 8. We can easily pick up Maven plugins and use them at will,
>> without having to write Ant targets or import specialized Ant task
>> classes.
>> 9. It makes creating distributions dead easy.
>> 10. It's much faster and more scalable than Ant.
>>
>> I can come up with more good reasons if you like.
>>
>> Not to mention that the sooner we move to it, the less work it
>> will be. If we wait, the code base will grow and just make it that
>> much harder to move to a new build system and directory structure.
>>
>> IONA has a number of projects, both open source and company-
>> internal, using Maven, and it's been working great for all of
>> them. Given my long history and experience with software
>> configuration management and build systems, I am generally
>> skeptical of tools like Maven that come along and make lots of
>> promises. However, my hat is definitely off to the Maven guys,
>> it's a great system that delivers the goods.
>
> I can point out that I introduced Maven to IONA,
And this is relevant how?
> so yes I know the benefits of Maven and I like it a LOT. So Steve I
> don't see this mail as a war, just the practicalities of what I
> have to do to make the code donation and move the project to
> Apache. I would like to complete this
> process so that I can know the apache svn is correctly imported and
> we can create a baseline build and make sure all is good. If we go
> to Maven I want us to discuss the issues, and how we want it set up
> and make sure that works for all.
You seem to think that I'm charging off and I'm going to commit a
Maven system without consulting anyone. I thought I already made it
clear I would wait until the move to Apache, and in general I would
never commit anything like this that the group doesn't approve, so I
don't know why you keep bringing this up. I'll write up and share the
report as I already promised, but meanwhile, spreading such FUD isn't
helpful.
Frankly, neither the current build system nor the Maven-based one I'm
working on is all that complicated. I've written build systems for
much more complicated and significantly larger systems than this one.
I understand and completely agree with the desire to keep it all
stable, and of course will do all I can to help ensure that
stability, but let's please not exaggerate the size or complexity of
this build system in an attempt to make this task appear harder than
it really is.
> For example, I want to see the impact on the dir structure and look
> if we want to make the C++ make structure match for example,want to
> know what we are going to do with Mina, etc... I don't think Maven
> is going to solve all the issues, and want us to make sure the ones
> that is does not we know how we are going to solve them.
Just to be clear, Maven will not solve anything for C++ or other
languages, just as Ant does nothing for them today either. C++ uses
make, while Ruby and Python don't really need such things. I'd say it
doesn't make sense to have C++ mimic the Java directory structure, as
C++ has no need for the deep package directories that Java forces.
All four languages mentioned have their own conventions, and we
should follow them for each language.
--steve
>
> Regards
> Carl.
>
>
>>
>> More details will be forthcoming as I progress my Maven work for
>> Qpid.
>>
>> --steve
>>
>> On Sep 7, 2006, at 5:40 PM, Carl Trieloff wrote:
>>
>>>
>>> Would like to park the maven discussion until Steve comes back
>>> with something that we can concretely
>>> discuss. My view is Maven does not help us any at this stage, and
>>> there are better uses of time right
>>> now on the code base, (but that is my view) and I might change it
>>> after Steve comes back with his
>>> research.
>>>
>>> Regards
>>> Carl.
>>>
>>> steven.x.shaw@jpmorgan.com wrote:
>>>> Could be wonderful. Maven makes alot of promises. I really like
>>>> he IDE file generation. Maven seem popular at Apache.
>>>>
>>>> I did spent a while trying to get Maven 2.0.2 and then 2.0.4
>>>> working to build Mina here at JPMC. It just wouldn't work. I
>>>> configured my http proxy. It couldn't download the maven-
>>>> compiler-plugin I think. At home it worked fine :). I figure
>>>> that I was having some kind of firewall issue but the error
>>>> messages leave alot to be desired! I ended up building mina-core
>>>> with a very short shell script...
>>>>
>>>> Steve.
>>>>
>>>> This communication is for informational purposes only. It is not
>>>> intended as an offer or solicitation for the purchase or sale of
>>>> any financial instrument or as an official confirmation of any
>>>> transaction. All market prices, data and other information are
>>>> not warranted as to completeness or accuracy and are subject to
>>>> change without notice. Any comments or statements made herein do
>>>> not necessarily reflect those of JPMorgan Chase & Co., its
>>>> subsidiaries and affiliates.
>>>>
>>>> This transmission may contain information that is privileged,
>>>> confidential, legally privileged, and/or exempt from disclosure
>>>> under applicable law. If you are not the intended recipient, you
>>>> are hereby notified that any disclosure, copying, distribution,
>>>> or use of the information contained herein (including any
>>>> reliance thereon) is STRICTLY PROHIBITED. Although this
>>>> transmission and any attachments are believed to be free of any
>>>> virus or other defect that might affect any computer system into
>>>> which it is received and opened, it is the responsibility of the
>>>> recipient to ensure that it is virus free and no responsibility
>>>> is accepted by JPMorgan Chase & Co., its subsidiaries and
>>>> affiliates, as applicable, for any loss or damage arising in any
>>>> way from its use. If you received this transmission in error,
>>>> please immediately contact the sender and destroy the material
>>>> in its entirety, whether in electronic or hard copy format.
>>>> Thank you.
>>>>
>>>
>>>
>>
>
Re: maven
Posted by Carl Trieloff <cc...@redhat.com>.
Steve Vinoski wrote:
> Not to start a protracted Maven war, but the benefits of Maven are
> many. In no particular order:
(I would not classify my last mail as an anti Maven mail)
>
> 1. Using it shows us as good Apache community citizens, as many new
> projects around here use it.
Ant is also Apache
> 2. Using the regular Maven directory structure enables new
> contributors to easily get up to speed.
> 3. It easily allows us to manage dependencies, which granted we
> currently have few of (though more than I initially thought), but that
> number will grow, for example as new persistence solutions are
> introduced.
Not for all our stuff today - issues around things like Mina
> 4. It enables us to easily produce snapshots and releases into the
> Apache repository so that other projects can be based on us.
> 5. It gives us simple set up for Eclipse and IntelliJ workspaces.
> 6. It gives us code coverage.
Not true, PMD, CheckStyle, etc integrations give us this
> 7. It gives us the ability to turn on code style checking at build
> time, assuming we want that someday (it's definitely got my vote).
Not a maven exclusive
> 8. We can easily pick up Maven plugins and use them at will, without
> having to write Ant targets or import specialized Ant task classes.
> 9. It makes creating distributions dead easy.
> 10. It's much faster and more scalable than Ant.
>
> I can come up with more good reasons if you like.
>
> Not to mention that the sooner we move to it, the less work it will
> be. If we wait, the code base will grow and just make it that much
> harder to move to a new build system and directory structure.
>
> IONA has a number of projects, both open source and company-internal,
> using Maven, and it's been working great for all of them. Given my
> long history and experience with software configuration management and
> build systems, I am generally skeptical of tools like Maven that come
> along and make lots of promises. However, my hat is definitely off to
> the Maven guys, it's a great system that delivers the goods.
I can point out that I introduced Maven to IONA, so yes I know the
benefits of Maven and I like it a LOT. So Steve I don't see this mail as
a war, just the practicalities of what I have to do to make the code
donation and move the project to Apache. I would like to complete this
process so that I can know the apache svn is correctly imported and we
can create a baseline build and make sure all is good. If we go
to Maven I want us to discuss the issues, and how we want it set up and
make sure that works for all.
For example, I want to see the impact on the dir structure and look if
we want to make the C++ make structure match for example,want to know
what we are going to do with Mina, etc... I don't think Maven is going
to solve all the issues, and want us to make sure the ones that is does
not we know how we are going to solve them.
Regards
Carl.
>
> More details will be forthcoming as I progress my Maven work for Qpid.
>
> --steve
>
> On Sep 7, 2006, at 5:40 PM, Carl Trieloff wrote:
>
>>
>> Would like to park the maven discussion until Steve comes back with
>> something that we can concretely
>> discuss. My view is Maven does not help us any at this stage, and
>> there are better uses of time right
>> now on the code base, (but that is my view) and I might change it
>> after Steve comes back with his
>> research.
>>
>> Regards
>> Carl.
>>
>> steven.x.shaw@jpmorgan.com wrote:
>>> Could be wonderful. Maven makes alot of promises. I really like he
>>> IDE file generation. Maven seem popular at Apache.
>>>
>>> I did spent a while trying to get Maven 2.0.2 and then 2.0.4 working
>>> to build Mina here at JPMC. It just wouldn't work. I configured my
>>> http proxy. It couldn't download the maven-compiler-plugin I think.
>>> At home it worked fine :). I figure that I was having some kind of
>>> firewall issue but the error messages leave alot to be desired! I
>>> ended up building mina-core with a very short shell script...
>>>
>>> Steve.
>>>
>>> This communication is for informational purposes only. It is not
>>> intended as an offer or solicitation for the purchase or sale of any
>>> financial instrument or as an official confirmation of any
>>> transaction. All market prices, data and other information are not
>>> warranted as to completeness or accuracy and are subject to change
>>> without notice. Any comments or statements made herein do not
>>> necessarily reflect those of JPMorgan Chase & Co., its subsidiaries
>>> and affiliates.
>>>
>>> This transmission may contain information that is privileged,
>>> confidential, legally privileged, and/or exempt from disclosure
>>> under applicable law. If you are not the intended recipient, you are
>>> hereby notified that any disclosure, copying, distribution, or use
>>> of the information contained herein (including any reliance thereon)
>>> is STRICTLY PROHIBITED. Although this transmission and any
>>> attachments are believed to be free of any virus or other defect
>>> that might affect any computer system into which it is received and
>>> opened, it is the responsibility of the recipient to ensure that it
>>> is virus free and no responsibility is accepted by JPMorgan Chase &
>>> Co., its subsidiaries and affiliates, as applicable, for any loss or
>>> damage arising in any way from its use. If you received this
>>> transmission in error, please immediately contact the sender and
>>> destroy the material in its entirety, whether in electronic or hard
>>> copy format. Thank you.
>>>
>>
>>
>
Re: maven
Posted by Carl Trieloff <cc...@redhat.com>.
Steve Vinoski wrote:
> Not to start a protracted Maven war, but the benefits of Maven are
> many. In no particular order:
>
> 1. Using it shows us as good Apache community citizens, as many new
> projects around here use it.
Ant is also Apache
> 2. Using the regular Maven directory structure enables new
> contributors to easily get up to speed.
not for C++, Python, Ruby etc.
> 3. It easily allows us to manage dependencies, which granted we
> currently have few of (though more than I initially thought), but that
> number will grow, for example as new persistence solutions are
> introduced.
Not for some of the Mina code we have, the other are trivial
> 4. It enables us to easily produce snapshots and releases into the
> Apache repository so that other projects can be based on us.
> 5. It gives us simple set up for Eclipse and IntelliJ workspaces.
> 6. It gives us code coverage.
Maven does not do this , it is the integration with PMD, checkstyle etc
that do this
> 7. It gives us the ability to turn on code style checking at build
> time, assuming we want that someday (it's definitely got my vote).
Agree with that but that is not exclusive to Maven
> 8. We can easily pick up Maven plugins and use them at will, without
> having to write Ant targets or import specialized Ant task classes.
> 9. It makes creating distributions dead easy.
> 10. It's much faster and more scalable than Ant.
>
> I can come up with more good reasons if you like.
>
> Not to mention that the sooner we move to it, the less work it will
> be. If we wait, the code base will grow and just make it that much
> harder to move to a new build system and directory structure.
>
> IONA has a number of projects, both open source and company-internal,
> using Maven, and it's been working great for all of them. Given my
> long history and experience with software configuration management and
> build systems, I am generally skeptical of tools like Maven that come
> along and make lots of promises. However, my hat is definitely off to
> the Maven guys, it's a great system that delivers the goods.
>
Now I have to say, that I introduced Maven to IONA, so yes I know the
merits and yes I like Maven a LOT. However this is not
a 100% Java project and it does not solve all the issues for this
project in my opinion, so if we do maven on the java I want us to do
it eyes open. I would also prefer to get the code move to apache
complete, make sure we can build in our new svn so that we have a
base line, and then if we choose to do maven (still believe we have some
things to discuss) it can be done on a branch and switched
cleanly.
(I hope it is clear that I am not against Maven, I just want us to have
the details ironed out before I am willing to vote, which I
believe Steve V. said he would create a proposal for us)
Regards
Carl.
> More details will be forthcoming as I progress my Maven work for Qpid.
>
> --steve
>
> On Sep 7, 2006, at 5:40 PM, Carl Trieloff wrote:
>
>>
>> Would like to park the maven discussion until Steve comes back with
>> something that we can concretely
>> discuss. My view is Maven does not help us any at this stage, and
>> there are better uses of time right
>> now on the code base, (but that is my view) and I might change it
>> after Steve comes back with his
>> research.
>>
>> Regards
>> Carl.
>>
>> steven.x.shaw@jpmorgan.com wrote:
>>> Could be wonderful. Maven makes alot of promises. I really like he
>>> IDE file generation. Maven seem popular at Apache.
>>>
>>> I did spent a while trying to get Maven 2.0.2 and then 2.0.4 working
>>> to build Mina here at JPMC. It just wouldn't work. I configured my
>>> http proxy. It couldn't download the maven-compiler-plugin I think.
>>> At home it worked fine :). I figure that I was having some kind of
>>> firewall issue but the error messages leave alot to be desired! I
>>> ended up building mina-core with a very short shell script...
>>>
>>> Steve.
>>>
>>> This communication is for informational purposes only. It is not
>>> intended as an offer or solicitation for the purchase or sale of any
>>> financial instrument or as an official confirmation of any
>>> transaction. All market prices, data and other information are not
>>> warranted as to completeness or accuracy and are subject to change
>>> without notice. Any comments or statements made herein do not
>>> necessarily reflect those of JPMorgan Chase & Co., its subsidiaries
>>> and affiliates.
>>>
>>> This transmission may contain information that is privileged,
>>> confidential, legally privileged, and/or exempt from disclosure
>>> under applicable law. If you are not the intended recipient, you are
>>> hereby notified that any disclosure, copying, distribution, or use
>>> of the information contained herein (including any reliance thereon)
>>> is STRICTLY PROHIBITED. Although this transmission and any
>>> attachments are believed to be free of any virus or other defect
>>> that might affect any computer system into which it is received and
>>> opened, it is the responsibility of the recipient to ensure that it
>>> is virus free and no responsibility is accepted by JPMorgan Chase &
>>> Co., its subsidiaries and affiliates, as applicable, for any loss or
>>> damage arising in any way from its use. If you received this
>>> transmission in error, please immediately contact the sender and
>>> destroy the material in its entirety, whether in electronic or hard
>>> copy format. Thank you.
>>>
>>
>>
>
Re: maven
Posted by st...@jpmorgan.com.
Hi Steve, I think it would be awesome to have a mvn2 build system. For
what it's worth I tried building the Apache Mina trunk again with mvn
2.0.4 but it still fails. However, I can build the ActiveMQ trunk with no
problem (other than I had to switch http proxies). Perhaps Mina is not
Maven 2 friendly.
The biggest problem with mvn2 is that mvn1 really sucked :)
Steve.
This communication is for informational purposes only. It is not intended as an offer or solicitation for the purchase or sale of any financial instrument or as an official confirmation of any transaction. All market prices, data and other information are not warranted as to completeness or accuracy and are subject to change without notice. Any comments or statements made herein do not necessarily reflect those of JPMorgan Chase & Co., its subsidiaries and affiliates.
This transmission may contain information that is privileged, confidential, legally privileged, and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is STRICTLY PROHIBITED. Although this transmission and any attachments are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by JPMorgan Chase & Co., its subsidiaries and affiliates, as applicable, for any loss or damage arising in any way from its use. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format. Thank you.
Re: maven
Posted by Steve Vinoski <vi...@iona.com>.
Not to start a protracted Maven war, but the benefits of Maven are
many. In no particular order:
1. Using it shows us as good Apache community citizens, as many new
projects around here use it.
2. Using the regular Maven directory structure enables new
contributors to easily get up to speed.
3. It easily allows us to manage dependencies, which granted we
currently have few of (though more than I initially thought), but
that number will grow, for example as new persistence solutions are
introduced.
4. It enables us to easily produce snapshots and releases into the
Apache repository so that other projects can be based on us.
5. It gives us simple set up for Eclipse and IntelliJ workspaces.
6. It gives us code coverage.
7. It gives us the ability to turn on code style checking at build
time, assuming we want that someday (it's definitely got my vote).
8. We can easily pick up Maven plugins and use them at will, without
having to write Ant targets or import specialized Ant task classes.
9. It makes creating distributions dead easy.
10. It's much faster and more scalable than Ant.
I can come up with more good reasons if you like.
Not to mention that the sooner we move to it, the less work it will
be. If we wait, the code base will grow and just make it that much
harder to move to a new build system and directory structure.
IONA has a number of projects, both open source and company-internal,
using Maven, and it's been working great for all of them. Given my
long history and experience with software configuration management
and build systems, I am generally skeptical of tools like Maven that
come along and make lots of promises. However, my hat is definitely
off to the Maven guys, it's a great system that delivers the goods.
More details will be forthcoming as I progress my Maven work for Qpid.
--steve
On Sep 7, 2006, at 5:40 PM, Carl Trieloff wrote:
>
> Would like to park the maven discussion until Steve comes back with
> something that we can concretely
> discuss. My view is Maven does not help us any at this stage, and
> there are better uses of time right
> now on the code base, (but that is my view) and I might change it
> after Steve comes back with his
> research.
>
> Regards
> Carl.
>
> steven.x.shaw@jpmorgan.com wrote:
>> Could be wonderful. Maven makes alot of promises. I really like he
>> IDE file generation. Maven seem popular at Apache.
>>
>> I did spent a while trying to get Maven 2.0.2 and then 2.0.4
>> working to build Mina here at JPMC. It just wouldn't work. I
>> configured my http proxy. It couldn't download the maven-compiler-
>> plugin I think. At home it worked fine :). I figure that I was
>> having some kind of firewall issue but the error messages leave
>> alot to be desired! I ended up building mina-core with a very
>> short shell script...
>>
>> Steve.
>>
>> This communication is for informational purposes only. It is not
>> intended as an offer or solicitation for the purchase or sale of
>> any financial instrument or as an official confirmation of any
>> transaction. All market prices, data and other information are not
>> warranted as to completeness or accuracy and are subject to change
>> without notice. Any comments or statements made herein do not
>> necessarily reflect those of JPMorgan Chase & Co., its
>> subsidiaries and affiliates.
>>
>> This transmission may contain information that is privileged,
>> confidential, legally privileged, and/or exempt from disclosure
>> under applicable law. If you are not the intended recipient, you
>> are hereby notified that any disclosure, copying, distribution, or
>> use of the information contained herein (including any reliance
>> thereon) is STRICTLY PROHIBITED. Although this transmission and
>> any attachments are believed to be free of any virus or other
>> defect that might affect any computer system into which it is
>> received and opened, it is the responsibility of the recipient to
>> ensure that it is virus free and no responsibility is accepted by
>> JPMorgan Chase & Co., its subsidiaries and affiliates, as
>> applicable, for any loss or damage arising in any way from its
>> use. If you received this transmission in error, please
>> immediately contact the sender and destroy the material in its
>> entirety, whether in electronic or hard copy format. Thank you.
>>
>
>
Re: maven
Posted by Carl Trieloff <cc...@redhat.com>.
Would like to park the maven discussion until Steve comes back with
something that we can concretely
discuss. My view is Maven does not help us any at this stage, and there
are better uses of time right
now on the code base, (but that is my view) and I might change it after
Steve comes back with his
research.
Regards
Carl.
steven.x.shaw@jpmorgan.com wrote:
> Could be wonderful. Maven makes alot of promises. I really like he IDE
> file generation. Maven seem popular at Apache.
>
> I did spent a while trying to get Maven 2.0.2 and then 2.0.4 working to
> build Mina here at JPMC. It just wouldn't work. I configured my http
> proxy. It couldn't download the maven-compiler-plugin I think. At home it
> worked fine :). I figure that I was having some kind of firewall issue but
> the error messages leave alot to be desired! I ended up building mina-core
> with a very short shell script...
>
> Steve.
>
> This communication is for informational purposes only. It is not intended as an offer or solicitation for the purchase or sale of any financial instrument or as an official confirmation of any transaction. All market prices, data and other information are not warranted as to completeness or accuracy and are subject to change without notice. Any comments or statements made herein do not necessarily reflect those of JPMorgan Chase & Co., its subsidiaries and affiliates.
>
> This transmission may contain information that is privileged, confidential, legally privileged, and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is STRICTLY PROHIBITED. Although this transmission and any attachments are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by JPMorgan Chase & Co., its subsidiaries and affiliates, as applicable, for any loss or damage arising in any way from its use. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format. Thank you.
>
>
Re: maven
Posted by st...@jpmorgan.com.
Could be wonderful. Maven makes alot of promises. I really like he IDE
file generation. Maven seem popular at Apache.
I did spent a while trying to get Maven 2.0.2 and then 2.0.4 working to
build Mina here at JPMC. It just wouldn't work. I configured my http
proxy. It couldn't download the maven-compiler-plugin I think. At home it
worked fine :). I figure that I was having some kind of firewall issue but
the error messages leave alot to be desired! I ended up building mina-core
with a very short shell script...
Steve.
This communication is for informational purposes only. It is not intended as an offer or solicitation for the purchase or sale of any financial instrument or as an official confirmation of any transaction. All market prices, data and other information are not warranted as to completeness or accuracy and are subject to change without notice. Any comments or statements made herein do not necessarily reflect those of JPMorgan Chase & Co., its subsidiaries and affiliates.
This transmission may contain information that is privileged, confidential, legally privileged, and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is STRICTLY PROHIBITED. Although this transmission and any attachments are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by JPMorgan Chase & Co., its subsidiaries and affiliates, as applicable, for any loss or damage arising in any way from its use. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format. Thank you.