ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicola Ken Barozzi <>
Subject Re: override
Date Thu, 31 Jul 2003 14:37:08 GMT

Conor MacNeill wrote, On 31/07/2003 15.44:

> On Thu, 31 Jul 2003 10:23 pm, Nicola Ken Barozzi wrote:
>>The only thing that comes to mind is that I cannot use super ion
>>dependencies, which is a nifty feature :-(
> Not sure why this would be needed. Just add <super/> as the first contained 
> task. All of the other dependencies will have been run by then (i.e. the 
> dependent targets of the original target, represented by <super/>).

I mean, if I need to run super before *other target dependencies*, I 
should do:

   <target name="test">
     <antcall target="anotherone">

While it's more resource efficient to have:

   <target name="test" depends="super,anotherone"/>

Of course, unless we introduce this (which is nice too):

   <target name="test">
     <depends target="anotherone">

>>>BTW, note that simple renaming of targets is not enough. Any use of a
>>>target name needs to be updated too (e.g. <antcall>). Can be done (at
>>>time of use) but may require tasks knowing their import prefix. The
>>>import task will need this to do cascade renaming.
>>Aha! Wait a sec, is this about the multiple inheritance-no-crosstalk
>>thing I outlined?
>>Could you please expand on this, I'm interested.
> Sure. Consider this change to my previous example. It represents rather poor 
> practice but can happen
>   <target name="test">
>     <property name="tricky" value="critical"/>
>     <antcall target="${tricky}"/>
>     <echo message="b.test"/>
>   </target>
> So the target that <antcall> has to really call is not known until the antcall

> is actually executed. Antcall has to evaluate the property, get the value 
> "critical", look at its own import prefix "b" and decide to therefore call 
> "b.critical". Some smarts may be possible there if, for example, b.critical 
> does not exist.

Now I get it.

But this is about scoping calls, not only renaming tasks. IIUC the 
xslt-like scenario described in the other thread does not need this 

Again IIUC, this renaming would effectively make the 
multiple-inheritance without import-line crosstalk that I talked about, 
but that in the other thread seemed to bring problems.

Aaarg @-|

I'm still confused...

> Similarly when imports are processed. Consider if a.xml imports b.xml with 
> prefix "b" and b.xml imports c.xml with prefix "c" then c's targets actually 
> need to be renamed to b.c.test in the final project To do tjhis the imprt 
> task needs to concatenate its own import prefix with given prefix. Of course 
> prefixes would be optional and then target name collisions would cause an 
> error, I think.

So this is what happens when we try to rename also the dependencies...

Nicola Ken Barozzi         
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)

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

View raw message