ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Reilly <peter.rei...@corvil.com>
Subject Re: antlibs and classloaders #2
Date Mon, 17 May 2004 09:49:04 GMT
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:mariano@fuegolabs.com] 
>>
>>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:bodewig@apache.org]
>>>>
>>>>On Mon, 10 May 2004, Jose Alberto Fernandez
>>>><jalberto@cellectivity.com> 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: dev-unsubscribe@ant.apache.org
>>>For additional commands, e-mail: dev-help@ant.apache.org
>>>
>>> 
>>>
>>>      
>>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
>>For additional commands, e-mail: dev-help@ant.apache.org
>>
>>
>>    
>>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
>For additional commands, e-mail: dev-help@ant.apache.org
>
>
>
>  
>


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


Mime
View raw message