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 oata.tasks.defaults.properties; 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:
http://cvs.sourceforge.net/viewcvs.py/*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)
-steve
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
