ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Loughran <>
Subject Re: Antlib autoloading (was Re: cvs commit: ant/src/testcases/org/apache/tools/ant/taskdefs
Date Mon, 12 Sep 2005 10:01:29 GMT
Jeffrey E Care wrote:
> I don't normally speak up on the developer list, but I thought this 
> discussion could benefit from the experience of a *very large* product 
> that uses Ant to build.
> We use Ant + our own extensions (Mantis) to build WebSphere Application 
> Server (and a good number of the stack products as well). The Mantis 
> extensions allow for build modularization both on a fine-grain (called 
> "component") and a coarse-grain (called "functional element") scale; 
> Mantis also has tasks that manage the dependencies between these modular 
> units, for purposes of constructing classpaths, scheduling build order, 
> etc.
> Given that our build is modular, as you might expect we have many hundreds 
> of individual build.xml files in WAS. With that many files it's difficult 
> to ensure that everyone is declaring typedefs correctly, so prior to our 
> adopting Ant 1.6 we were modifying an Ant 1.5.4 distribution to always 
> include the Mantis tasks in; it was just 
> easier for our users that way. Now that we're on an Ant 1.6.5 base we're 
> using namespaces + antlibs to make the Mantis tasks available, which IMO 
> is better than doing a typedef, but on a large scale it's still difficult 
> to ensure that everyone is doing the right thing.
> So, with all of that in mind, I really do like the suggestion of 
> autoloading type & task definitions from META-INF/antlib.xml; I also 
> understand Dominique's concerns about transparency & staying in control. 
> Perhaps this behavior could be controlled with a command-line switch, say 
> "-autoload" or something along those lines, such that the default behavior 
> would be as it is today (i.e. no autoloading), but by specifying the 
> switch Ant could search its classpath to discover the antlibs. This would 
> also yield a nontrivial performance enhancement, as currently each of our 
> modules is effectively reloading our antlib, whereas I would think that 
> autoloading would be done once (when Ant is bootstrapped).

This sounds like the largest Ant build project I've heard of, excluding 
Gump itself, which is so loosely coupled it doesnt really count. We 
have, what, 30 build files in ours and I am still struggling to deal 
with refactoring it to be more effective. The big problem I have in mine 
is that with a single ${root.dir}/common.xml containing most stuff, it 
is inordinately brittle. So I am breaking it into separate build files 
with lots of cross <imports>, mandatory namespace declarations for all 
tasks, presets, etc.

My project rework proposal is here:*checkout*/smartfrog/core/antbuild/doc/third_generation_build_process.sxw

for anyone who wants to view and comment.

I hadnt thought about autoloading; I am happy with explicit loading of 
stuff into their own namespaces, but want to make it easier for projects 
to get access to my definitions (or even importable libraries)


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

View raw message