The dependency ordering addition is pluggeable... you just provide a
resolver implementation. I created only one such implementation for my own
custom format, but a GUMP resolver format would be easy to write. It's just
the matter of parsing the GUMP descriptor, and creating instances that
implements DependencyNode (or provide a DependencyNodeAdapter if it doesn't)
that my DependencyResolver class knows how to sort. Probably Jenny could be
used to load the GUMP project instances, and a dependency adapter
implemented for it.
Note how buildpath returns a double array. This is to allow building in
parallel projects when possible: Consider the usual diamond A, B & C depends
on A, D depends on B & C, my resolver gives you:
{ {A}, {B,C}, {D} } which tells you can run B and C in parallel. Any project
within an inner array can be build in parallel provided their dependencies
(earlier stuff in the outer array) have been build before.
I already submitted SubAnt.java (the older version).
I now have these other classes I'd submit provided enough interest (the last
two are not of interest to anyone but me):
BuildPath.java
BuildPathResolver.java
DependencyCycleException.java
DependencyNode.java
DependencyNodeAdapter.java
DependencyNodeImpl.java
DependencyResolver.java
DependencyResolverTest.java
TahoeBuildPathResolver.java (private impl of BuildPathResolver)
TahoeProject.java (private impl of DependencyNode)
The build path resolver is specified and configured in a usual Ant way:
<buildpath ident="buildpath"
resolverClassname="com.lgc.buildmagic.TahoeBuildPathResolver">
<param name="destdir" value="${destdir}" />
<param name="dependencies" value="${dependencies}" />
</buildpath>
And the class loaded must implement the BuildPathResolver interface defined
below:
package com.lgc.buildmagic;
import java.io.File;
import org.apache.tools.ant.types.Parameterizable;
/**
* Helper class allowing a <code>BuildPath</code> to be dynamically
* inferred instead of being statically defined.
* <p>
* Provides the famous <em>extra level of indirection</em> which is the
* solution to all computing problems ;-)
*
* @author <a href="mailto:[EMAIL PROTECTED]">Dominique Devienne</a>
* @version Nov 2002 - Copyright (c) 2002, Landmark Graphics Corp.
*
* @see BuildPath
* @see SubAnt
*/
public interface BuildPathResolver
extends Parameterizable {
/**
* Gets the sorted array of all the build directories or build files
* that need to be build.
*
* @return a non-<code>null</code> but possibly empty array of build
* files and/or build directories. All returned files being
* directories instead of file will be appended with the anfile
* name defined by the <subant> task
* (which defaults to build.xml)
*/
File[][] getBuildPath();
} // END class BuildPathResolver
-----Original Message-----
From: Nicola Ken Barozzi [mailto:[EMAIL PROTECTED]
Sent: Friday, March 14, 2003 8:56 AM
To: Ant Developers List
Subject: Re: subant
Dominique Devienne wrote, On 14/03/2003 15.50:
> I actually signed off <lsync>, not <subant>, technically, but in practice
I
> give both. Anything I submit to BugZilla is good for the taking, and I'll
> refrain to include my usual/automatic copyright notice in the future.
Yees! lsync is koooool :-)
> Sorry to hear you suppressed passing down the current target name... That
> one of the feature of that task I won't live without. But that's OK, I'll
> keep using my own task then (actually I would anyhow for the dependency
> ordering I have).
Centipede does it using the Gump project descriptor. Could it be a wise
thing to stick to one version of the two only, or does it make sense to
have this anyway? (just asking)
--
Nicola Ken Barozzi [EMAIL PROTECTED]
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
