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">
<super/>
<antcall target="anotherone">
</target>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">
<super/>
<depends target="anotherone">
</target>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 renaming.
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 [EMAIL PROTECTED]
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
------------------------------------------------------------------------------------------------------------------------------------------ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
