qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rajith Attapattu" <rajit...@gmail.com>
Subject Re: maven
Date Wed, 06 Sep 2006 12:45:46 GMT
+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 <gsim@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!
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message