ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicola Ken Barozzi <>
Subject Re: override
Date Fri, 01 Aug 2003 15:26:35 GMT

Dominique Devienne wrote, On 01/08/2003 17.14:

>>-----Original Message-----
>>From: Conor MacNeill []
>>Sent: Friday, August 01, 2003 9:24 AM
>>To: Ant Developers List
>>Subject: Re: override
>>On Fri, 1 Aug 2003 10:47 pm, Nicola Ken Barozzi wrote:
>>>How can this thing be done while shielding interactions?
>>You make the renaming optional.

So you mean it's an ||, I cannot have both :,-(   ;-)

>><import file="a.xml"/>
>><import file="b.xml"/>
>>All of a's and b's targets go unprefixed. If those builds use targets
>>are provided by the main build, or by the other, unprefixed, import then
>>there is no problem. This situation thus allows the cross-interactions. 

IIUC you mean that it's exactly like using <include>, right?

>>need to decide a few issues. Is mutliple definitions of a target
>>an error or does one definition win. If one wins, which one - the first or
>>the last. I prefer to have this as an error.
> Me too. Should be an error, forcing the user of the imported files to
> explicitly resolve the conflicts, thanks to renaming. Might be a little more
> work, but tons more predictable, and will not surprise anyone.

Seems it won't change the way it works now, as I would still be able to 
redefine the target, only that I have to override it with the override task.

>><import file="a.xml" prefix="a"/>
>><import file="b.xml" prefix="b"/>
>>In this case each import's targets are prefixed and thus will not collide.
>>Specific overriding in the build could make desired connections.
>><override target="a.init">
>>	<antcall target="b.init"/>
> I agree with Nicola Ken that using <antcall> is wasteful resource-wise, and
> that what it should really be is:
> <override target="init">
>   <depends target="a.init" />
>   <depends target="b.init" />
> </override>

Can't it be instead:

  <override target="init" depends="a.init, b.init"/>

It's more similar to how target works.
I'm ok with either though.

> I'm also starting to think that targets from a and b that do not conflict
> should *not* be renamed, 

IIUC that's how it should work now, with the only difference that the 
single, non colliding, target has two names (init and a.init).

> and that renamed targets from a and b should not be
> call-able directly from the command line, but only from within the build
> file itself, to compose them as shown above.

Why? I see no reason for it.

> I already wrote about this, but I'll say again that nobody should be aware
> of the renaming taking place but the build file that does the
> importing/renaming.

Sorry, I don't understand this sentence in it's practical implications.
Could you please expand a bit?

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