Hi Antoine, I manage project dependencies using the technique described at http://www.exubero.com/ant/dependencies.html This uses vanilla Ant features to manage transitive dependencies between subprojects (but not external dependencies).
For internal subprojects, I will generally configure all my subprojects to "publish" their jars to a well known directory, so that dependant projects can pull the jar into their classpath. External dependencies are checked into version control, and updated in a controlled manner. In general, I think that this is simpler and more robust than relying on the maven infrastructure (though I really *do* like the repository concept). Cheers, Joe On Mon, 12 June, 2006 8:29 pm, Antoine Levy-Lambert wrote: > 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 <[email protected]> > 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]
