qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Vinoski <vino...@iona.com>
Subject Re: maven
Date Tue, 05 Sep 2006 20:47:57 GMT
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  


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