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 Wed, 21 Nov 2001 17:14:42 GMT
On Wed, 21 Nov 2001 12:22:42 +1100, Jeff Turner
<> wrote:

>is one useful trick here: declare a 'main' target which is the default, and
>then call others from that.  Then you can have declare it's
>default target ('jar' in most projects, 'dist' in others). Having a
>guaranteed-present 'main' target also means you can type 'ant clean main' on
>any project, and have it work, rather than the slower 'ant clean ; ant'.

Works, but only for one target/algorithm. I'm thinking e.g. about
adding/removing targets that adress specific EJB server needs, like
calls to Weblogic targets which are unwanted in projects addressing
other servers.

[snip; Rolf:]
>> 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
>> downloadable.
>Wohoo :) Would my build system fit in here?

It is intended to be an OpenSource project, so I prefer not to work in
the cathedral there... ;-)

>Btw, if you want to see an *inspired* build system, have a look at
>jakarta-taglibs' :) Each subproject script 'inherits' from it's owner, and each
>target has 'pre' and 'post' targets (also overridable).. it's very cool.

Thanks for this pointer. At teh beginning I was really investigating
almost all build files I could get, but nowadays almost everybody uses

>I've always relied on the example snippets in the docs.
>Perhaps we could expand on those?

Good idea to organize for standard fragments. I'd also like to create
a FAQ for the not-so-obvious problems.

>OTOH, there's also the architectural issues that are only become apparent when
>trying to build the full thing. Issues like property naming (I still haven't
>figured that out),

Currently, I try to stick with a Java-package like hierarchy, but I'm
not too happy about it.

>property granularity (when can you safely just 'hardcode' a

Never! ;-)

>use of 'subtargets' etc. Then there's also all the ways that the project
>filesystem structure affects the build file. If you don't separate runtime jars
>(src/lib) from compile-time jars (/lib), you need hacky logic to separate them
>when building distros, .wars etc. Same with .html and .properties files in

In addition, I already needed *separate* compile-time jar file
directories to distinguish between Application (JDK 1.3) and Applet
code (JDK 1.1). Was forced to split the javac targets, too...

>> - 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?
>I wish I'd written better CVS logs at the time ;P I originally had it
>${basedir}, and changed for some good reason that I've now forgotten. Something
>was unhappy about the absolute path, and I concluded that relative is more
>flexible (you can always prepend ${basedir}).

It is more flexible, for sure, but ${basedir} is more "secure", then

>> - 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)?
>Yep, but I've no idea what those file patterns are.

Not really generic issue, right, although JPGs, GIFs etc. are a safe

[snip; Rolf:]
>> 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?
>As for 'hooks for extensions', do you like my build-docs.xml system? :) Usually
>'docs' builds javadocs, but if there's a build-docs.xml file present, that gets

Sub-buildfiles as well as other mechanisms (e.g., the documented
DOCTYPE hack). Actually, it would be our task to find out what is the
best extension mechanism for which challenge.

>In general, I think both are useful. I suspect many people have a small
>personal collection of build.xml experiments, useful tricks and other snippets.
>I'm sure these could be useful to others (if appropriately documented). But for
>all the reasons outlined above, I think you need to go further and give'em a
>full working system to play with :)

Ok. So before we start or modify another Sourceforge project, let's
try to fix an agenda. Here are suggestions for the contents of such a
project, at least those which are my top candidates:

1. Very basic, no-frills projects for the absolute beginner
(javac, javadoc, java targets; just for the sake of those who like to
copy and paste a little during learning, to motivate them by "instant
gratification"; BTW, this is also useful at least for all of these
quick&dirty "Hello World" tests I do)

2. FAQ
(It seems this mailing list is a good indicator of what s a FAQ)

3. Reasonable "strategies" for recurring problems
(compatible ad combinable in [build] files, without forcing users to
search the build files and throw out what they don't need; this item
is probably the hardest part, since we need to find good ways to
combine functionality while keeping the files clear; IMHO also
multi-platform issues should be handled in generic manners, wherever

4. Meta-Programming/Unleashing XSLT

Quite an amount of Ant meta-programming can be done using this, like
creating build scripts you're going to call in the next step and
similar. I'd prefer this kind of transformations over sed/awk-style
stuff. However, I must admit that XSLT is quite complicated for the
beginner and might be considered "downer".

Some "downers" I'd like to avoid, from my perspective:

- unforced Guru-style programming
- switching cascades to select platform-dependent binaries and adapt
the command line arguments they need, according to the platform
- enforcing do-it-as-I-do-or-get-out
- assuming 100% identical developer machines
- assuming one's favourite tool is also the darling of others
- ...

What's your opinion?
Best regards,

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

View raw message