ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Antoine Levy-Lambert" <anto...@gmx.de>
Subject Re: Re: Maven vs. Ant?
Date Mon, 12 Jun 2006 19:29:16 GMT
Hi,

I am interested by this thread, as the project I am working for might need a tool able to
manage inter-project dependencies and a repository.

Has anyone compared maven and ivy ? And what about dpml ?

Regards,

Antoine

-------- Original-Nachricht --------
Datum: Mon, 12 Jun 2006 17:39:01 +0100
Von: Steve Loughran <stevel@apache.org>
An: Ant Users List <user@ant.apache.org>
Betreff: Re: Maven vs. Ant?

> EJ Ciramella wrote:
> > Maven (2) works REALLY well with transitive dependencies (something ant
> > doesn't).  
> 
> Agreed. Ivy and the maven2 tasks do this, though not so tightly
> integrated.
> 
> >So much is available right out of the box (keeping build
> > files simple and easily maintained.  Why would you want an additional
> > archive server?  Why store things in your scm tool that won't be
> > versioned?  Since all the jar files are in binary format, you're storing
> > the entire version when you check in a jar, not just the changes since
> > last version.  In addition to this, I've seen companies have a lib
> > directory per branch/project.  Why sync the same jar in two (or many
> > more) locations when you can keep it in one?  This makes even more sense
> > when you have a bunch of projects that use the same binary.  Having
> > maven maintain these binary files (and the associates classpaths) is so
> > much nicer than having some entry in an ant script.
> 
> Any project that considers longevity or offline rebuilding must think 
> about how to archive all their dependencies. What if the repositories go 
> away? What if a lawsuit forces some jar to be pulled.
> 
> You may also need a private repository to store stuff that isnt in open 
> source, or just not in the public repositories. This is no different 
> >from putting the JARs in a lib/ dir, except you have to make up stub 
> poms that declare some or zero dependencies.
> 
> Being able to switch versions just by changing property files is nice...
> 
> > 
> > About the directory structures - these CAN be overridden in maven, BUT
> > the beauty of this is by getting all the projects to conform, there's
> > less entry in the pom.xml files to say where is source, where do the
> > classes go, where does the built up jar go.  Additionally, I've seen
> > over the years people sticking source where ever they feel it belongs.
> > Maven (when using the defaults) keeps everything properly packaged so
> > one project looks like the next (and so on...).
> > 
> > Maven is all about modularity - if you are forced to build everything at
> > once (utils/db/app/web/etc classes) and you have source level
> > dependencies, then this isn't for you.  If you have a very modular
> > product (if you just need to deploy a new war with some freshly
> > recompiled classes that are at that level, not in some core package),
> > then maven makes handling these builds very easy.
> 
> I have had mixed experiences with it. Maven1 was trouble, especially 
> with its snapshot logic. I havent used m2 enough to come to an opinion.
> 
> > On a side note, maven2 is horrendously documented.  Be prepared to spend
> > a great deal of time tinkering and waiting for replies on the mailing
> > list if you opt to go this route.
> 
> I worry about its stability, though things are improving. The ant tasks 
> can be a bit up and down from version to version, which implies they 
> dont get tested enough.
> 
> -steve
> 
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@ant.apache.org
> For additional commands, e-mail: user-help@ant.apache.org

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@ant.apache.org
For additional commands, e-mail: user-help@ant.apache.org


Mime
View raw message