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 [mailto:[EMAIL PROTECTED] Sent: Monday, June 12, 2006 3:29 PM To: Ant Users List Subject: Re: Re: Maven vs. Ant? 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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
