ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Steve Loughran" <>
Subject Re: refactoring a large project
Date Sun, 21 Jul 2002 05:28:30 GMT

----- Original Message -----
From: "Shackelford, John-Mason" <>
To: "'Ant Users List'" <>
Sent: Saturday, July 20, 2002 12:53
Subject: RE: refactoring a large project

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

I think so too, but we dont have that much on how to clean up existing
projects. FYI the deployment to tomcat stuff in ch7 had too many antcalls
in; chapter 18's deployment build file was a complete rework.

I have this vision in the future of intellij IDEA 5.0 adding ant refactoring
to a build file, with operations like
    -make selection a property
    -extract selection into new target
    -extract fileset into referenced fileset
    -extract targets into new build file


I think this would be great, but also kind of scary: if we need this in our
build files, then we are losing the complexity war.

> I already wrap the scripts that launch ant for various platforms with my
> 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
> file. This would reduce the size of the build file (with entity includes
> both versions) by a third and would ensure that it wouldn't continue to
> as new build versions are added.

I dont see anything wrong with custom perl scripts to do stuff that ant cant
do, except in maintenance costs. I am nearly as scared of the
system-build-and-CD-burn-from-a-clean-Clearcase-VOB perl script as I am of

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

hey, wow, this makes you the first person to cite us :)

Now I feel the burden of responsibility...

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

how about using the <foreach> task in ant-contrib to parse a list of targets
and call them, so you can do

ant -Dtargetlist=build,deploy-snowy,deploy-muttley,deploy-rover

and have something underneath crack them. Also, the perl script is there to
let you easily change your invocation process across multiple systems.

nb, DD's little task to get the current target into a property is a slick
little addition to simplifying some of the big project stuff. Dominque: are
we going to see the code or do I have to re-implement it now you've given me
the idea (maybe in ant-contrib :)


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

View raw message