ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mariano Benitez <>
Subject Re: antlibs and classloaders #2
Date Tue, 11 May 2004 12:03:38 GMT
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:

we have a local/tests directory were all tests modules reside (20+), we 
have a build.xml at the top level for global cleans builds, runs, etc, 
and at the module dir, anothere build.xml for single module runs. I use 
an <import file=${basedir}/include/xml/> to define stuff at the module 
level, and a <import file=${basedir}/server-include.xml/> for global 
tests runs.

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
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.

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?

Thanks for the help on this matter.


Jose Alberto Fernandez wrote:

>>From: Stefan Bodewig [] 
>>On Mon, 10 May 2004, Jose Alberto Fernandez 
>><> 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"/>
>   <antlibresolve mylib:ns="<ignored value>" />
>In this second, we get the URI from "ns" attribute which is in that
>the implementation could use the new NS aware features that were added
>Jose Alberto
>To unsubscribe, e-mail:
>For additional commands, e-mail:

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

View raw message