Jose Alberto Fernandez wrote:
--- Dominique Devienne <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED]
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
-- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
