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.....http://sourceforge.net/projects/mockobject 
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.sh, build.bat, 
buildtemplate.jar, junit.jar, ant.properties, 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 needs.
thanks and I hope someone likes this whacky idea,
dean

Reply via email to