ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Erik Hatcher <>
Subject Re: don't copy build.xml files ever again.....
Date Wed, 15 Sep 2004 11:17:54 GMT
Also, a very nice and similar project is megg, which resides at 


On Sep 12, 2004, at 7:33 PM, Charles Daniels wrote:

> Your idea isn't so whacky.  In fact, it's called Maven ;-)
>> -----Original Message-----
>> From: Dean Hiller []
>> Sent: Sunday, September 12, 2004 12:07 AM
>> To:
>> Subject: don't copy build.xml files ever again.....
>> 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 needs.
>> thanks and I hope someone likes this whacky idea,
>> dean
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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

View raw message