ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hartin, Brian" <>
Subject RE: project dependency
Date Tue, 07 Oct 2003 16:53:58 GMT

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

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

I think it would have it uses, but the main drawback of this method is that
you need the code/sandboxes of all the dependencies. Often, that's not
desirable. The route we've taken is to publish the build artifacts for all
dependencies (not just a JAR in our case, but a ZIP containing JARs,
DLLs/SOs, XML descriptors, scripts, etc...) with built-in version and
dependency info (it's in fact in a separate small .properties file for now).
Each project declares its own dependencies, which it must download
explicitly (pull model, not push).

This way, I can work one a single project A with lots of dependencies, but I
still only need one code base (A), and the pre-built dependencies are simply

I do have a mechanism in place for these times when a developer needs to
work on several projects at the same time, so that one can say "use this
sandbox for this dependency instead of downloading the dependency". The rub
is that it's all ad-hoc and proprietary of course...

My point is that it's the same kind of approach Maven uses, and to me it's
the right approach. --DD

> -----Original Message-----
> From: Shackelford, John-Mason []
> Sent: Tuesday, October 07, 2003 11:10 AM
> To: 'Ant Users List'
> Cc: Hartin, Brian
> Subject: RE: project dependency
> Excellent thread!
> This is an issue we are tackling at Pearson now as we maintain projects
> made
> up of many components each of which may be reused in other contexts. One
> of
> the problems with traditional ant-based solutions is that they rely on a
> master build file that maintains the dependency graph--but this does not
> work in a situation where each component is both a top level component in
> some situations, or merely dependency in others. We need each component to
> be aware of its own dependencies, calling build files of the projects it
> depends on if they are out-of-date.
> Our current implementation makes so many <ant> calls to achieve this that
> it
> performs poorly. We are beginning work on a new task or set of tasks that
> look something like subant with the following differences:
> Each component will have a component.xml file which will define the other
> projects required. Our task will quickly scan through these component.xml
> files, build a dependency graph and then execute the builds in the proper
> order. Thus we do not have to maintain the whole graph in whichever
> component happens to be the top-level component for a particular project.
> While ant's depency resolution works great within a single build file, we
> hope to provide this same kind functionality among the many build files of
> a
> project.
> We are also looking at defining the up-to-date checks in the component.xml
> file so that we can use a component's own up-to-date check to determine
> whether or not we even need to issue an <ant> for a particular build file.
> Would anyone else find this useful? If there is enough interest to warrant
> it we'd be happy to work with others in the community to ensure that our
> solution fits in favorably with 1.6.

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

This email may contain confidential material. 
If you were not an intended recipient, 
Please notify the sender and delete all copies. 
We may monitor email to and from our network. 

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

View raw message