ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Costin Manolache <>
Subject Re: NameSpace & antlib was (Re: polymorphism)
Date Tue, 29 Apr 2003 16:52:56 GMT
Nicola Ken Barozzi wrote:

> ...
>> The proposal <antlib> provides a task <antlib> which can be used to
>> load libraries manually. Al the same time there are hooks on the code
>> for an autoloading mechanism to be supported. In escence, it would
>> allow ANT's main() to do something like:
>> - get all antlib.xml from the classpath ( using getResources);
>> - process each one of the antlib.xml resources found so that
>> all definitions get registered.
>> All the processing is provided by a static method of the Antlib task.
>> In principle this was designed just for loading the core at load time,
>> we could expand it to allow loading all jars (antlibs) in the classpath,
>> which means all antlibs in the ANT/lib directory.
> This I really liked but Costin IIRC put it down in favor of compulsory
> explicit loading.

<loader> ( which is a wrapper around AntClassLoader ) allows adding to
 the core loader, to solve junit-like problems, but can also allow 
operations on arbitrary classloaders.

I think the class loading - even if it is a very difficult problem - 
shouldn't  be the major concern. There are systems with far more complex 
needs ( jboss, tomcat, etc ).

>> The main issue is how to enforce ordering to deal with dependencies
>> between the antlibs.
> Or simply do not deal with dependencies, ie antlibs must not (yet)
> depend on on the other, except for the core ones.

Using an unified class loader ( at least as default ) - like jboss is doing,
or like JMX loading policy  - has a lot of benefits.  It also has some cases
that are not well covered - so we'll probably need to deal with both
"unified loader" and "loader hierarchy" cases.

My concerns with getResources() as oposed to 
getResource( PACKAGE/antlib.xml): 

1. startup time. In order to load one library you need to process all 
of them. It can be resolved with caching the result and looking at .jar
modifications. Most likley we'll have dozens of antlibs - and that'll only 
grow in time. The processing of (all) TLDs at startup ( for tomcat ) adds a
very visible overhead on startup, and at least tomcat is a long-running

2. Placing multiple antlibs in a single jar may be trickier.

3. It may place too much emphasis on the .jars and filesystem layout.

4. A bit harder to control ( as we know from c-logging and JAXP ), 

5. Explicit control over what antlibs are to be used - versus loading
everything. Well - I like "magic" loading, but a lot of things in ant
are done explicitely. 

I have no problem accepting a getResources() solution ( just like I'm 
ok with using XML - but not any XML :-), but those issues should be

A lot of the "mess" in ant is the result of doing some things without
considering all implications or just as side effect of how code happened
to work. That's why I'm so strongly for breaking things down to individual
problems instead of a bundle solution. 


View raw message