ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <davidjen...@directvinternet.com>
Subject Re: refactoring a large project
Date Sat, 20 Jul 2002 22:37:57 GMT
Don't know if it would help you, but I am a fan of the jboss buildmagic
system.  It is oriented towards a large project being organized into
modules that can be compiled separately.  There is a master build script
that runs the build scripts for sets of modules and has per-module targets
that pull the results from the modules into an "assembly area".  You can
define module sets in the master build file or on the command line.

There's documentation somewhere on the jboss site for it, but I find it
easier to look at the build.xml files.  build/build.xml is the master file,
the others are all module build scripts.  I just spent a significant amount
of time helping to refactor a rather impenetrable build process into this
system and was very pleased with the results.

david jencks

david jencks

On 2002.07.20 15:53:50 -0400 "Shackelford, John-Mason" wrote:
> Dominique,
> 
> 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="versioned.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? 
> 
> Yikes!
> 
> 
> John-Mason Shackelford
> 
> Software Developer
> NCS Pearson - Measurement Services
> 2510 North Dodge St.
> Iowa City, IA 52245
> 319-354-9200x6214
> shacjo@ncs.com
> 
> --
> To unsubscribe, e-mail:   <mailto:ant-user-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: <mailto:ant-user-help@jakarta.apache.org>
> 
> 
> 

--
To unsubscribe, e-mail:   <mailto:ant-user-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:ant-user-help@jakarta.apache.org>


Mime
View raw message