Re: antlibs and classloaders #2

[Peter Reilly]

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.
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).
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"/>
Peter
     

Jose Alberto Fernandez wrote:
From: Mariano Benitez [mailto:[EMAIL PROTECTED] 

Let me get this right.. this task would define the antlib classes the 
moment it is invoked, and it should be used on the top level 
buildfile, 
this way the subbuilds/subants/ant/antcall targets have the antlib 
already loaded, right?

I explain a bit my build files structure for testing:
   

[snip...]
 

Up to this moment I need to define the tasks in boths includes using 
<typedef uri="...." loaderref="..." classpathref="..."/> because I 
cannot pass classpath to antlibs. I also added in both includes an 
<if><not><isset property="antlibs.define"/></not><then>...the typedef 
stuff. </if> to do this only once for all the builds.
I use a lot of subant, antcall, ants and it is very difficult 
to control 
in all the builds that the do use inheritall="true", since 
otherwise the 
<if> would not find the property and redefine the tasks.

   

 


Here I would advocate to have the new condition <isDefined/>
that I mentioned before. Which will not rely on inheritAll
but will look at the definintion dictionalries directly.
 

Could you put this structure as it would be in 1.6.2 with the 
antlibresolve and antlib classpath, at least what you imagine 
it might be?

I like the <antlibresolve> solution, as long as it does not 
redefine the 
tasks, or at least there is an option not to do so. Would it 
be possible 
to add to typedef that possibility?

   

<antlibresolve/> the only thing it does is make sure the antlib URI
gets processed. As if you were calling task in the space of the antlib.
Actually on the incarnation as <mylib:antlibresolve/>
it would have been a noop task whose only side-effect is causing the
loading of the antlib. If you call it 20 times it would only load
the antlib the first time, like any other task would.
(humm this may be still the best solution, just make every antlib define
this task).
How to deal with your classloaders, that is a different thing
completely. 
- Is it possible to define them inside the antlib (or are they buildfile
dependent)?
- I had proposed in the past a naming convention to associate a
classpath/loader
with a particular URI. But all this is just open talk at the moment.
- Maybe <antlibresolve/> can do some of this, but then its definition is
not as clean
as one would want.

Jose Alberto
 

Thanks for the help on this matter.
MAriano
Jose Alberto Fernandez wrote:
   

From: Stefan Bodewig [mailto:[EMAIL PROTECTED]
On Mon, 10 May 2004, Jose Alberto Fernandez
<[EMAIL PROTECTED]> wrote:
  

       

Would the following solve this problem generically?
<!-- 
 This task is automatically available for every ANTLIB
 and its only function is to force the loading of the library
 if necessary. Force the lazy loading.
-->
<mylib:antlibresolve/>
    

         

looks like a reasonable compromise.
The alternative would be a built-in task that takes the
antlib URI, this wouldn't even require any magic taskname.
<antlibresolve uri="..."/> or even <antlibresolve prefix="..."/>.
  

       

I have no problem, one way or another, as long as I do not 
     

have to type 
   

the whole URI again ;-) This is why I want to use the NS prefix 
instead. Is there an way for the task to get the information needed 
(the URI)?

Since a lot of this is resolved by the parser (prefix-->uri) 
     

mapping, I 
   

was trying to make sure we do not get bog by the design. So 
     

as long as 
   

we can get the info necessary by just saying:
 <antlibresolve prefix="mylib"/>
or
 <antlibresolve mylib:ns="<ignored value>" />
In this second, we get the URI from "ns" attribute which is in that 
space. the implementation could use the new NS aware 
     

features that were 
   

added recently.
Jose Alberto
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

     

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
   

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

 


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]