ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dominique Devienne <DDevie...@lgc.com>
Subject RE: project dependency
Date Tue, 07 Oct 2003 16:31:49 GMT
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
downloaded.

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 [mailto:john-mason.shackelford@pearson.com]
> 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: user-unsubscribe@ant.apache.org
For additional commands, e-mail: user-help@ant.apache.org


Mime
View raw message