ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "EJ Ciramella" <>
Subject RE: Re: Maven vs. Ant?
Date Tue, 13 Jun 2006 13:47:33 GMT
I'd stick to using mavens dependency management within ant (having set
up my first assembly the other day, I wanted to pull out my hair).

Ivy just makes things messier afaic, just more ivy.xml files everywhere.

-----Original Message-----
From: Antoine Levy-Lambert [] 
Sent: Monday, June 12, 2006 3:29 PM
To: Ant Users List
Subject: Re: Re: Maven vs. Ant?


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 ?



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

> EJ Ciramella wrote:
> > Maven (2) works REALLY well with transitive dependencies (something
> > 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
> > 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
> > the entire version when you check in a jar, not just the changes
> > 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
> > when you have a bunch of projects that use the same binary.  Having
> > maven maintain these binary files (and the associates classpaths) is
> > 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
> away? What if a lawsuit forces some jar to be pulled.
> You may also need a private repository to store stuff that isnt in
> 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
> > 
> > About the directory structures - these CAN be overridden in maven,
> > the beauty of this is by getting all the projects to conform,
> > 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
> > Maven (when using the defaults) keeps everything properly packaged
> > 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
> > 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
> > On a side note, maven2 is horrendously documented.  Be prepared to
> > a great deal of time tinkering and waiting for replies on the
> > list if you opt to go this route.
> I worry about its stability, though things are improving. The ant
> can be a bit up and down from version to version, which implies they 
> dont get tested enough.
> -steve
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message