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


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.

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]



Reply via email to