qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Carl Trieloff <cctriel...@redhat.com>
Subject Re: maven
Date Tue, 05 Sep 2006 21:08:40 GMT


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.


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

View raw message