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