ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Joe Schmetzer" <...@exubero.com>
Subject Re: Re: Maven vs. Ant?
Date Tue, 13 Jun 2006 14:11:56 GMT
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 <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


Mime
View raw message