ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Douglas Brown" <>
Subject RE: project dependency
Date Tue, 07 Oct 2003 17:52:14 GMT
I've already built another alternative based on Ant called Savant. I wrote
about it previously on the mailing list:

Savant may not be exactly what you are looking for because it doesn't try to
automatically download and install dependent COTS or Open Source projects.
It may just be me, but in general I feel that level of automation can lead
to problems: different developers with different versions of dependent
projects; copies of the same projects but built with different options; etc.
This can lead to a lot of trouble when trying to track down test failures or
when integrating work from a bunch of different developers. Instead, Savant
assumes a common directory and build structure for dependent products.

You can find info on my approach at Both
documentation and source are available at that site. You should probably
read the "Getting Started" doc first. I still need to add another doc with a
lot more examples, but what's already there should be enough to get you
going. It's all Open Source.

I also have some dependency graph generation tools I can make available. One
such tool allows the user to specify a slew of jar files on the command line
and then the tool will determine what relationship each jar file has on the
others. The tool is based on jdepend and the output is an XML file. It is
mostly useful if you have a bunch of legacy jar files for which you are not
certain of their relationship, but if there is interest, I can make it
available as well.

Note, Savant is *not* a replacement for Ant, it is just a way of setting up
an enterprise environment using Ant.


-----Original Message-----
From: Dominique Devienne [] 
Sent: Tuesday, October 07, 2003 1:11 PM
To: 'Ant Users List'
Subject: RE: project dependency

Hey, I'm no Maven expert ;-) I'm just a lurker there. Remember, the only
time I tried it, I failed miserably to set it up.

But I do now that Maven is a moving target, and they move forward quite
rapidly. What you describe may well have been fixed already. They also now
have a MultiProject plugin on top of the reactor, so again things may be
better now.

Although I like building things myself, my custom developments to fit our
needs resemble very much what Maven and Gump provide, albeit very
primitively, and I'd rather use something with momentum and a community
behind rather than my crappy stuff.

And to answer John-Masson, we do worry about things being out of date when
we download them (each is CruiseControlled), which is why I have no my plate
to use a *consistent* set of dependencies instead of the latest of
everything. I won't even try to describe what a consistent set is ;-) And
I'll also build everything/all projects from source at time T, very much
like Gump (I'll leave the details out), but for nightly builds. The former
solution is for integration builds during the day.

To stay in sync, we have set up CruiseControl to monitor not only the CVS
repo of the project, but also were its dependencies are published, so when
something is published, a CC build of all the stuff depending on it will get
triggered. My colleague coined that 'the ripple effect', which converges
eventually to an in-sync state.

We do not have all the answers. People who have successfully deployed Maven
for their many projects (almost) all rave about it...


> -----Original Message-----
> From: Hartin, Brian []
> Sent: Tuesday, October 07, 2003 11:54 AM
> To: 'Ant Users List'
> Subject: RE: project dependency
> Dominique,
> Isn't Maven's approach, when the reactor is used, really a blend of the
> two?
> Suppose project A depends on projectb-1.0.jar.  When you run a Maven build
> for A it will attempt to download projectb-1.0.jar from the repository (or
> a
> specified URL), but you can also use the <reactor> tag in the maven.xml
> file
> to ensure B is built each time.
> The problem we (John-Mason and myself) had with Maven is that it assumed
> that you would always have a 'master' project with no dependencies.  If a
> project has any dependencies listed in its project.xml file, the Maven
> process will fail immediately, never getting to the <reactor> tag.  In
> other
> words, there was no way to build an arbitrary project X in such a way that
> the dependency graph was built, and only projects in the subgraph
> reachable
> from X were built or downloaded, if necessary.
> Brian Hartin
> Pearson

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

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

View raw message