ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Shackelford, John-Mason" <>
Subject RE: refactoring a large project
Date Sat, 20 Jul 2002 19:53:50 GMT

After doing a little more reading and thinking am thinking about adopting a
solution. (BTW the Hatcher and Loughran book looks really good. They have
some good suggestions on managing large projects.)

My solution is not particularly ant-like, but I have not come up with a way
to achieve my objectives otherwise. I am eager for feedback. You were right:
the top level <antcall> is not really the problem, it is others that I will
remove. However using the <antcall target="${version}/>
approach still leaves me with a very large build file which is becoming
sluggish. Adding a few more versions will drive it into the ground. 

I already wrap the scripts that launch ant for various platforms with my own
which detect the JVM path and set ANT_HOME, etc. A target called setup.env
(a dependency for all others) detects when property files change and
regenerates these shell scripts accordingly. I could just parameterize the
script wrapper, and have set.env do some token substitution so that I call
different build.xml files depending on the build version set in the property
file. This would reduce the size of the build file (with entity includes for
both versions) by a third and would ensure that it wouldn't continue to grow
as new build versions are added.

The only other way I can think of to dynamically load different build files
is to use <ant> and to use a ${target} property to pass down which target to
execute. This is the suggestion made by Hatcher and Loughran (p. 216) and it
is a good one but has the following drawbacks:

1. it requires developers to use a lengthy command line option; e.g. intead
of $ ant build.all, I have to say $ ant -Dtarget=build.all.
2. you can't execute multiple targets (which is something we do constantly)

Now if I could somehow execute all the targets specified on the command line
in a build file dynamically loaded by a master build file according to the
build version specified in a property file, that would be something. Perhaps
this is a job for a listener? 


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