Jeff Turner wrote:
>Hi,
>
>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.)
Dave
>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
