ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rolf Katzenberger <>
Subject Re: [POLL] jakarta-ant-templates (Generic Ant-based project templates)
Date Tue, 20 Nov 2001 17:08:14 GMT
Hello Jeff,

On Mon, 19 Nov 2001 21:36:39 +1100, Jeff Turner
<> wrote:

>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

The same goes for me, maybe my hordes are a bit smaller. ;-)

>My very first build.xml was copied from an Apache project, and hacked to
>meet my needs. Subsequent projects were all cut-and-paste affairs. Over
>time, as I noticed that most projects are pretty similar, I formalized
>this by creating a "generic" build.xml, and an associated template
>project structure.
>This system has been working nicely for many months.  Project-specific
>customizations are all kept to an external file, which
>allows the build.xml to evolve independently.

This is an interesting approach. Did you manage to put all project
specifics into properties files? Sometimes I needed additional
targets, which is why I did not manage to maintain a truly generic
build.xml so far. What I did in the past was to place *developer*
specifics into, since most of my colleagues have
their own ideas where to install their software.

>Of course, what constitutes a "good" build.xml is extremely subjective,
>and even if the scope is strictly regulated I doubt we could reach
>"consensus". Multiple solutions are fine with me. But *whatever* we can
>achieve together is better than what we can achieve independently.
>The big winner should be newcomers, who just want to get their code
>building. They can now download a "turnkey" solution; plug your code in
>and go :) Ant gains new users, and today's newbies are tomorrow's
>So what I'd like to know from y'all:
>1) Does this sound workable? (and for what definition of "this"?)


>2) Do you have a generic build system to contribute?
>If there's critical mass, let's wander off and form a sourceforge
>project to discuss it; come up with categories, associated solutions,
>document pros and cons; then come back here and twist arms until they
>let us form a jakarta-ant-template subproject :)

Well... ummm... :o) I already started such a sourceforge project a
while ago, Ant Heap ( -
currently in pre-alpha, but already a tiny appetizer release is

My goal was to provide copy&paste ready build scripts for
not-so-trivial challenges that are useful for people who do not really
(need to) know in-depth how things in build.xml work.

>To get the ball rolling, I've put up my attempt at:
>I've attached -projecthelp output at the end, to give you a brief idea of what
>it does. But let's discuss the general concept on this thread, rather than my
>Looking forward to everyone's comments :)

Downloaded this and liked it. Here we go:

- usage of something like dependencies.xml is a good idea; I also like
the concept of having sub-buildfiles with well-defined names

- as you already mentioned, opinions vary what constitutes a "good"
build.xml; personally, I don't feel like *imposing* certain styles of
e.g. unit testing or certain tools (CVS is not used everywhere), which
is why I'd prefer "building" blocks in smaller sample build.xml files
that give the users freedom of choice. Of course, all build.xml files
must be compatible with each other, then.

- in several places in build.xml, the dot '.' was used for starting
relative paths; im not sure whether ${basedir} wwas the better choice
for this?

- copy-resources copies a whole directory; maybe copying only specific
file patterns prevents one from deploying unwanted artifacts (backup
files of graphics programs, HTML editors, and the like)?

- the javadocs target has a hardcoded copyright year (2001) that is
placed e.g. into the window title. Maybe the copyright of javadocs
always pertains to the year of the creation of the docs, so we could
make use of tstamps date formatting capabilities ("YYYY") to create a
property for the 4-digit years?

Seen from a general point of view, would you say that building
smaller, reusable build.xmls that highlight just one aspect would
work? Or is it preferrable to have a (big) generic build.xml with e.g.
hooks for extensions? Or are there even better options?

Best regards,

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

View raw message