ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jose Alberto Fernandez" <jalbe...@cellectivity.com>
Subject RE: antlibs and classloaders #2
Date Mon, 17 May 2004 10:45:34 GMT
> From: Peter Reilly [mailto:peter.reilly@corvil.com] 
> 
> 
> I meant to respond to this earlier, but did not get the chance.
> 
> 1) use of classpath in an antlib.
> I have tested using a classpath within an antlib:
> 
> ~/.ant/lib/x_call.jar containing:
> x/antlib.xml
> <antlib>
>   <typedef resource="x/antlib.xml">
>     <classpath path="${user.home}/apps/x/x.jar"/>
>   </typedef>
> </antlib>
> 
> This works fine, but depends on a possible bug in ant
> see: bugzilla 28782
> 
> http://issues.apache.org/bugzilla/show_bug.cgi?id=28782
> 
> The problem is that the typedef in the antlib should pick up 
> two antlib.xml resources, the one in  
> "${user.home}/apps/x/x.jar" and the one in x_call.jar 
> (itself). This will should cause no-ending recursion.
> 
> The bug means that this does no happen - the resources in the 
> parent classloader are currently not visible to the child 
> classloaders.
> 
> If the bug is fixed, an infinite recursion will happen.
> This could be stopped by typedef checking if it has already 
> been executed.  This can be done by using "user" properties - 
> but this will pollute the property names, or by exending 
> (again) Project to have a map of objects that gets copied to 
> its child projects. Using non-user properties or references 
> will not work as <*ant*> tasks can stop the non-user 
> properties and references being copied to the child 
> processes. Using a static map in typedef will not work as 
> sibling projects will incorrectly interact.
> 

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.

> 2) antlibresolve
> I like the idea of antlibresolve:
> 
> <antlibresolve uri="antlib:net.sf.antcontrib.cpptasks">
>    <classpath path="${CPP_HOME}/cpptasks.jar"/> </antlibresolve>
> 
> This would use ComponentHelper#checkedNamespaces to see
> if the antlib has been resolved or not, which means that
> it can be called many times without a problems.
> 
> 
> Using:
> <project xmlns:cpp="antlib:net.sf.antcontrib.cpptasks">
>   .....
>   .....
>   <cpp:antlibresolve>
>     <classpath path="${CPP_HOME}/cpptasks.jar"/>
>   </cpp:antlibresolve>
> </project>
> 
> May be considered as a short-hand (antlibresolve is now a 
> reserved name and may not be used as a task/type in an antlib).
> 

You are right, but I like it since it reduces the amount of retyping
of long URIs that we would have otherwise. As, how to treat such
"reserve word", is to be automatically added by <antlib/> as a
predefined
task of all namespaces.

> 
> However:
>   <antlibresolve prefix="cpp">
>   </antlibresolve>
> 
> is very problematic. - for example the antlibresolve may be in a
> macrodef:
>    <macrodef name="resolve">
>       ...
>      <antlibresolve prefix="@{myprefix}"/>
>      <antlibresolve prefix="x" xmlns:x="antlib:a.b.c"/>
>       ...
>    </macrodef>
> 
>    <resolve myprefix="x" xmlns:x="antlib:x.y.z"/>
> 

I see the problems...

Jose Alberto

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org


Mime
View raw message