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 process. 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 considered. 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. Costin
