> From: Peter Reilly [mailto:[EMAIL PROTECTED]
>
>
> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
