> From: Costin Manolache [mailto:[EMAIL PROTECTED]
> 
> 
> 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.
> 

I agree. But let me just say that I do not believe that in general
people should just shove evry jar in the world in ANT/lib
(this should be basically the core libraries).

What I thought was to have a separate directory ANT/antlib (or something)
where people can put libraries which they can load easily on demand.
Something like:

        <antlib library="jboss-ant.jar"/>

which will just look for ANT/antlib/jboss-ant.jar ant load that using the
classloader methanism whatever it is. 

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

I prefer to keep things simple, one antlib == one jar. It is the same for
all other things around ejbjars, wars, etc.

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

I still think that when you are really working on a project, you will have your 
own
directories in the basedir containing the antlibs required for the project.
And your buildfile will just load the antlibs manually.

        <antlib location="${myantlibs}/special.jar"/>

or we could have something like:

        <antlib>
                <fileset dir="${myantlibs}" includes="*.jar"/>
        <antlib>

or something of the sort. Having such a construct working fine for
manual loading would make providing an autoload just trivial.
The main() will just create the fileset for "ANT/lib/*.jar" and just 
let the <antlib> do its job.

My point is to provide the correct level of manual control and then
we can make a decision whether the bootstrapping process of ANT can just
run the task to do any autoloading.

> 
> 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. 
> 
I agree completely. What I would suggest is to decide what manual
capability we want so that it is convinient to users. Once you have that
we can see how the core can use it for autoloading.

Jose Alberto

Reply via email to