ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Erik Hatcher" <>
Subject Re: Ant 2 et al.
Date Tue, 09 Jul 2002 16:01:00 GMT
----- Original Message -----
From: <>

> But the last time I looked at Struts for example, it was a lot better on
> documentation in the code bsae than Ant was. Some projects get people who
> feel docs and clean code are important, others don't. It's all about
> what's important to them.

Also to be fair to Ant, the docs have been geared primarily towards "users",
not task developers.  So, sure, the API could use better docs, but it also
could use a lot of refactoring also, which we all agree on  (a rewrite being
the extreme refactoring!).

I'm of the opinion that Ant's primary strength will be in its API and core
tasks, and not the build.xml that we all know and love today.

Just a quick take on my current itches:  project abstraction.  I want to
define a global project "template" (although that word is not quite
appropriate) that does the standard init, compile, jar stuff.  And "extend"
it (this is why template is not quite the right word) to add in some extra
stuff, or tweak how the "inherited" functionality works.  I'm not sure how
all this would play out - and I want to eventually explore how this would
work in Mutant and Myrmidon before choosing a path to go down. It bugs me
that I have to add the same stuff in every build.xml (property file loading,
environment loading, creating build directory, etc, etc).  I think with
applying OO principals to project and target is where its at, although I
haven't formalized any of that thinking yet.  Just postulating.


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

View raw message