ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dean Hiller" <>
Subject don't copy build.xml files ever again.....
Date Sun, 12 Sep 2004 04:06:49 GMT
Well, I had a very whacky idea that seems to be working very well.  Ever find yourself copying
a build.xml file only to add stuff to it later like code coverage and wish you could add to
all those other projects you copied the build.xml file from.

Well try this new project out for size..... has
a buildtemplate.  If you download it and run "java -jar buildtemplate.jar -directory <project>"
it installs itself with ant, junit, a code coverage tool for testing all built into one. 
Ok, I don't here any "that's cool" just yet.  But now try this, start 10 more projects with
this buildtemplate.  Then, take the buildtemplate and upgrade ant, or junit, or code coverage,
or make changes to the build.xml file, or add the findbugs tool to it.  Then to update the
10 projects with the new build.xml or new junit, or whatever, just drop the buildtemplate.jar
right over where it put itself when you first ran "java -jar buildtemplate.jar -directory
<project>" which is in the <project>/tools directory.

It is a pretty sweet way of maintaining alot of similar services build environments.  What
is really nice, is you only have to check in, build.bat, buildtemplate.jar, junit.jar,, dist.xml each time you upgrade.  ant, emma, jdk package lists, ant-contrib
and a bunch of goodies are hidden inside the buildtemplate.jar.

It is quite a weird way of going about things but it seems to work out very well in these
days of SOA, and a module/project for every service when needing that same buildtemplate.

This is just meant to be a pattern for others.  The buildtemplate you need may be differen
if doing J2EE, etc, but you can start with this implementation and modify it for your own
thanks and I hope someone likes this whacky idea,

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message