Jose Alberto Fernandez wrote:
>> 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.
That means more filesystem specific code. You can't use getResource() to
get META-INF/antlib.xml from a specific jar - unless you're sure that's
the only jar with that res. in the classloader. So you either operate on the
jar with Zip, or you have to do ugly tricks with the loaders.
Plus - a lot of people have the strange habbit of placing the version number
in the jar file name ( jboss-ant-1.2.3.jar ). Every time you upgrade an
antlib, all build files that use the jar will need to change ( or you'll be
forced to use indirection ).
If you use namespaces - which seems to be what many people want - you'll
either have to use ${} in the namespace ( I think most agree this is
indeed a bad use of ns ), or the namespace will change if the versioned jars
are used ( bad again ).
>> 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.
"Prefer" is one thing, "require everyone" is another.
If we place the descriptor in packages - both preferences are possible.
Look - I'm fine with either solution, I just have a feeling that we're
making the decision without really considering all implications. I don't
like "versioned jars", and I don't like big jars combining too many things.
>> 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"/>
Again - this will have implications in the namespaces.
> 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 people ( myself included ) seem to like a "repository" that
is shared by multiple projects - instead of having all the jars in CVS
or managed manually.
We must keep in mind this use case - and the fact that the file
names may change ( versioning ) and the repository may have more than
we need ( startup time, etc ).
Costin
