ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicola Ken Barozzi <>
Subject Re: <import> enhancement, it's done, but do you like how it works ?
Date Thu, 11 Jul 2002 20:37:09 GMT

Jose Alberto Fernandez wrote:
>  --- Dominique Devienne <> wrote: >
> You can have as many import levels as you want, and
>>any file will be
>>imported only once (and cycle are taken care of
>>too). So it's like all
>>imported files belong inside the importee. I'm not
>>too sure how that plays
>>with Nicola Ken's newest super. Scheme ;-) I think
>>it complicates things a
>>bit... Not sure yet how to do it better. --DD
> I have no problem with the import (i.e., include) side
> of it. That is fine. All my comments are with respect
> to the rewriting scheme for target overiding.
> I am suggesting a rewriting scheme that renames each
> overridden target with the file it comes from:
>   targetA --> path/A.xml::targetA
> and then having ${ant::super(targetA)} expand to the
> correct rewrite:
>   <target name="targetA" 
>           depends="${ant::super(targetA)}"/>
> becomes:
>   <target name="targetA" 
>           depends="path/A.xml::targetA"/>
> this is robust no matter how many levels of nesting
> you have.

Ok, now I understand :-)

We could have roughly the same by doing something /like/:

     <target name="targetA"

I don't like your syntax that much, and the property use too,
since users may want to set the value with a property, but
they cannot easily, because you would need double property expansion...

Basically what you are saying is that using many super.super. etc can 
lead to subtle errors with multiple imports...

It's because we have a flat space, and so we don't have proper nesting 
and encapsulation...

Let's say that builda.xml imports buildb.xml, which imports buildc.xml.
Also builda.xml imports directly also buildc.xml.
All have targetc.
Now, will targetc of builda.xml override the one of buildb.xml or of 

Houston, we have a problem.

It's like name clashing in Java, where different packages are made to 
prevent it.

Basically imported builds are imported packages, so they must have 
unique names somehow.

Since we have a flat system, the most simple way is that every imported 
targets can also be called with the full path (sort of...)

Still not sure that this fixes the problem though...

Dr. Pietschmann ;-) any hint on how XSLT works with these problems?
I'll be looking now in the specs, but I'm sure that your Mulberrylist 
experience can be again of some help :-)

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