ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeffrey E Care <ca...@us.ibm.com>
Subject Re: Antlib autoloading (was Re: cvs commit: ant/src/testcases/org/apache/tools/ant/taskdefs AntlibTest.java)
Date Sat, 10 Sep 2005 14:12:39 GMT
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).

Just my $0.02.

JEC
-- 
Jeffrey E. Care (carej@us.ibm.com)
WebSphere v7 Release Engineer
WebSphere Build Tooling Lead (Project Mantis)


Dominique Devienne <ddevienne@gmail.com> wrote on 09/09/2005 05:57:07 PM:

> On 9/9/05, Stefan Bodewig <bodewig@apache.org> wrote:
> > > So, any ideas how this could be acomplished?
> > Load all resources from META-INF/antlib.xml at startup and process
> > them, I'd say.
> 
> But doesn't that go against Ant's tradition to not have auto-magic
> things, but instead spell things out explicitly, usually in the build
> file?
> 
> I'd rather we extend <typedef> to accept a <fileset> of AntLib jars to
> load, possibly thru META-INF/antlib.xml, than auto-magically loading
> all possible antlibs visible from the classpath. At least you can see
> it and start looking at the jars it loads.
> 
> How would you know looking at a build file where a task is coming from
> otherwise?
> 
> Also, for example, I have quite a few AntLibs which are in ant/lib,
> and thus on Ant's classpath, but I don't use all of them in all my
> builds. They're there because it's our official supercharged
> production Ant distro, but loading all of them in builds that require
> none or just a few is wasteful.
> 
> I personnally want to stay in control of what gets loaded in each
> build. I don't want to prevent others to do it if they fancy it, as
> long as it's not forced on me. --DD
> 
> PS: And BTW, Matt's point about conflict resolution is a good one.
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> For additional commands, e-mail: dev-help@ant.apache.org
> 

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message