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
