ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Reilly <>
Subject Re: antlibs and classloaders #2
Date Mon, 17 May 2004 12:42:58 GMT
I would agree with you on all points (I think).

Mariano Benitez wrote:

>> This things sound like we are using the wrong abstraction here.
>> <typedef/> inside an <antlib/> 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.

This classpath could be defined by a <antlibresolve/> task.

>    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 <path>, 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 <path>) 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.

One antlib may "resolve" other antlibs if antlibresolve was an allowed 
task in an antlib.


> 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:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message