ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Turner <>
Subject Re: [POLL] jakarta-ant-templates (Generic Ant-based project templates)
Date Wed, 21 Nov 2001 23:16:06 GMT
On Wed, Nov 21, 2001 at 06:14:42PM +0100, Rolf Katzenberger wrote:
> On Wed, 21 Nov 2001 12:22:42 +1100, Jeff Turner
> <> wrote:
> [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... ;-)

Hmm? What have ESR cathedrals got to do with it?

> >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)


One for webapps would be nice. Brian Ewins' Tomcat App Developers
Guide-based system sounds like the right sort of thing.

When someone adopts and improves the 'no-frills' project at the expense
of some additional build.xml complexity, what happens? Can they submit
their modified build system?

How about as a policy, we agree to accept *any* variation on an existing
build system, so long as it's differences/advantages/disadvantages are
documented. We then put it in a CVS branch. On the website, we have a
complete geneaology, so people can choose where on the
complexity:functionality axis they want to start from.

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

There are generic Ant FAQs all over the place. What makes this one

> 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
> possible)

Sounds good.
> 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".

I haven't yet needed this. Anyone have a real-world example they'd like
to contribute?

> 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

This is what I want to avoid with the above "accept all enhancements,
branch freely, document differences" policy.

> - assuming 100% identical developer machines
> - assuming one's favourite tool is also the darling of others
> - ...

This sort of forum would naturally be host to discussions on
controversial topics such as 'should jars be in CVS?'. Fine; but I think
that as a policy, we should make no judgements. Let the offerings from
CVS reflect the diversity of opinions.


> What's your opinion?
> Best regards,
> Rolf

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

View raw message