Mailing-List: contact user-help@ant.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Ant Users List" <user@ant.apache.org>
Received-SPF: neutral (hermes.apache.org: local policy)
Message-ID: <004701c4987d$edff6c10$4345fea9@silverdragon>
From: "Dean Hiller" <dean@xsoftware.biz>
To: <user@ant.apache.org>
Subject: don't copy build.xml files ever again.....
Date: Sat, 11 Sep 2004 22:06:49 -0600
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0044_01C4984B.A3094780"

------=_NextPart_000_0044_01C4984B.A3094780
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

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


------=_NextPart_000_0044_01C4984B.A3094780--