>This things sound like we are using the wrong abstraction here.
> inside an should use the antlib classloader
>as the parent for any subsequent classloader.
>
>I do not see why that should cause an infinite recursion.
>
>I feel like we have a conceptual mismatch between antlib "the jar"
>with the code, and antlib "the resource with the XML definitions".
>We are not treating them in a symetric way or as a unit. And
>hence we are get into all this conflicting behaviour.
>
>
I would like to pick from here and try to describe my understanding of
the concepts.
Antlib: I see this as a a definition of tasks within a namespace that
involves all the jars required to resolve the execution of the tasks. To
put it plainly, I see it as the antlib.xml with a classpath.
So for me that defines completely the antlib and the extra classpath
should be added to the antlib classpath.
Also, for me is accidental that the antlibs should be located in the
$ANT_HOME/lib or in a -lib , actually the antlib definition should
start from the antlib.xml, wherever it is, and then create a classloader
based on the antlib definition.
For the special case were the antlib jars are located in the base
ant classpath ($ANT_HOME/lib or -lib ) I would not allow adding a
classpath since the antlib should be completely contained within the
base ant classpath, only when the antlib jars are outside I would allow
defining an extra classpath.
Also, defining antlibs in either way (being inside base ant
classpath or outside) should behave the same way, they should be
idempotent, meaning that once they are defined, they should not be
overriden, I understand that it is not wise to use the same uri for
different antlibs, the user should always try to pick unique names for
the antlibs, otherwise we go back to a single namespace.
This is my understanding of antlibs, it is probably out of synch with
what you envision on this, but I wanted to let you know what I thought
antlibs were about.
My 2 cents.
MAriano
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org