ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Shackelford, John-Mason" <>
Subject versioning projects with the ant runner
Date Fri, 09 Aug 2002 15:10:52 GMT

Many moons ago now, I discussed refactoring a large build process (nearly
5,000 line of ant build instructions) with Dominique Devienne who suggested
that I consider writing my own replacement for
The recommendation was a good one and using this approach I am to load only
targets applicable to a specific build version (as well as those common to
all build versions) rather than everything at once. This approach
substantially improves performance for me as well as making the whole
project more maintainable.

If the committers are interested I would be happy to work on a patch for that would make this functionality more generally

My proposal is to add a command line option to ant: -versionbuild which
would cause ant to look for a properties file on the classpath that has a
"build.version" key which indicates which version of the project to build.
The class uses this value to do the equivalent of
ant -buildfile build-${build.version}.xml -Dbuild.version=${build.version}.
Each build file can then do entity includes to bring in targets common
across build versions and version specific targets.

Why would anyone want to do this? 

Nested build files with <ant> calls work fine for builds that have one (or a
very few) basic path. For more complicated builds that need to expose many
targets for the developer to call from the command line, using <ant> to call
down is impractical since these targets are either not available when
invoking the command line on the top level build file, or else every target
in a child file that needs to be exposed must have a target in the parent. A
third option is to require developers to know which build file to use for a
given target and to call it directly via the -buildfile option--also
impractical when developers are executing some numerous targets scores of
times through out the day. 

Combining all targets into one very large build file exposes them all, but
also creates a maintenance headache. The approach many use is to do entity
includes and have separate entity files for each bit of functionality. As a
build matures and needs to support multiple versions of the same
application, these entities naturally segregate targets common to all
versions of the application from those which change from version to version.
One may then easily produce a build file for a new version of an application
by including all the common entities:

<!DOCTYPE project [

	<!ENTITY includeBase     SYSTEM "buildfiles/common/base.ent">
	<!ENTITY includeJUnit    SYSTEM "buildfiles/common/junit.ent">
	<!ENTITY includeShipPrep SYSTEM "buildfiles/common/ship-prep.ent">
	<!ENTITY includeEMS-v32         SYSTEM "buildfiles/v32/ems-v32.ent">
	<!ENTITY includeEMS-shrserv-v32 SYSTEM

I would argue that:

1. Large build systems are not all that uncommon, and will be increasingly
common as time wears on. 

2. Having many paths of execution (i.e. exposing many targets to the user)
can be important when ant is used interactively as part of a development

3. Versioned applications are a universal phenomenon. Reuse of build targets
across versions is not only possible, but probable as a build matures.

4. Typing:

$ ant -buildfile build-${build.version}.xml -Dbuild.version=${build.version}
mytarget1 mytarget2

every time one wants to say:

$ ant mytarget1 mytarget2

is royal pain. Solving the problem with a shell script is not really in the
spirit of ant.

Forgive my long-windedness. If any of the committers are interested I will
generalize the code I've written, integrate it back into and provide a patch.

John-Mason Shackelford

Software Developer
NCS Pearson - Measurement Services
2510 North Dodge St.
Iowa City, IA 52245

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

View raw message