ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dominique Devienne <>
Subject RE: refactoring a large project
Date Sat, 20 Jul 2002 20:13:04 GMT
I'm still a little confused by your setup. The Ant script generating the
shell script to launch itself based on properties file is a little out there
I think... Don't know the specifics you have to deal with, but I find this
suspicious! Anyways...

Something I realized when asnwering another post a few days ago was that by
setting the last argument inside ANT_OPTS to a Java class name, you can
intercept the Ant Java command line before Ant's Main class sees it. The
args your own Java main class will see are all the args Ant will receive,
prepended by You were saying earlier the version
property indicating which version of your software to build was inside a
properties file!? I assume it's in a well know location!?

If it is, load it in your main:

import java.util.Properties;
Properties props = new Properties();
String version = props.getProperty("build.version");

Then alter Ant's command line by adding (or substituting) the correct
"-buildfile build"+version+".xml" argument on that command line.

then simple call;

A little farfetched maybe, but who knows, it might just be your answer????


-----Original Message-----
From: Shackelford, John-Mason []
Sent: Saturday, July 20, 2002 2:54 PM
To: 'Ant Users List'
Subject: RE: refactoring a large project


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: <>

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

View raw message