Jose Alberto Fernandez wrote:
> --- Dominique Devienne <DDevienne@lgc.com> 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"
depends="imported.A.xml.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...
hmmm...
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
buildc.xml?
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 nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <mailto:ant-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:ant-dev-help@jakarta.apache.org>
|