ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Walend <>
Subject Re: [POLL] jakarta-ant-templates (Generic Ant-based project templates)
Date Mon, 19 Nov 2001 13:45:31 GMT
Jeff Turner wrote:

>I was wondering, how do people feel about developing "common",
>"universal", "generic" build.xml scripts for common needs?
>I have hordes of mini-projects on the go, the end result of each is:
> - a jar file
> - some javadocs
> - some config files
> - the above all packaged as a .tar.gz and .zip
My take on how to do most of this is really different... I needed a way 
for people with no experience with ant and little experience with 
java/unix/internet foo to come up to speed quickly.

So I broke things down into subprojects, each of which has these 
targets: props, clean, prepare, product-jar, test-jar, test, 
publish-source, source-tar and install.tar.

    props sets all the properties
    clean blows away the build tree
    prepare sets up the build tree
    product-jar makes the jar file for the subproject
    test-jar makes a jar of unit tests for the subproject
    publish-source slaps a license and email addresses on the source code
    source-tar tars up the result of publish-source
    install-tar creates a tar ball of the whole subproject.

Each project has several subprojects and one uberproject that builds all 
the subprojects and sets up its distribution. (I put the javadoc in the 
uberproject. It makes setting up all the cross links much easier.)

Each subproject stays tightly focused, usually only involving a package 
or two. That tends to limit a build file to contain only one or two 
*weird* things, like native code compiles, database calls, or EJB 
packaging. The build.xmls stay small and simple. It also encourages 
people to use unit testing. Since most people spend lots of time on only 
a few subprojects, they don't often compete to edit a build file. The 
subprojects build in tens of seconds, so its no big deal to blow away 
everything before each subproject build, and developers can rebuild 
while grabbing a quick sip of coffee. Uberproject builds are fairly rare 
(hourly or so) and very reliable because the subprojects are 
compartmentalized. Generally as projects grow more complex, they simply 
bud off more subprojects instead of growing huge build files.

The main drawback to this approach is that properties wind up copied in 
every subproject with slight differences. I've at least isolated them in 
a target so that they can come from a common source at some vague point 
in the future.

I hope that adds something. I'll have a nice example of this up in a few 
days on source forge in a project named somnifugi. (Requested it Sunday. 
Will probably get it by Tuesday.)



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

View raw message