<!-- Here you want to redefine "sel", incorporating its current definition, whatever that may be. How do you do it? -->
I agree it's diserable, but it's indeed not currently possible to override a reference and at the same time reuse the previous definition, if any. You can do the override alone, albeit with a warning. This is hurting Ant's ability to define generic and reusable build files. When I designed a generic build for my previous companie's projects, I really wished for the ability to use a <super>-like tag that 'inserts' the overriden target or id'd type.
In the commented zone above, the following creates a circular reference: <selector id="sel"> <and> <selector refid="sel" /> <contains text="foo" /> </and> </selector>
Yep, obviously.
This doesn't yield the desired result either: <selector id="_sel"> <and> <selector refid="sel" /> <contains text="foo" /> </and> </selector>
Why doesn't this work? It should, no? Sure, having the use a new id is not great, but...
<selector id="sel" refid="_sel" />
You should still get a circular reference because of the way references are resolved.
Yep, circular it is.
The only way is: <copyref refid="sel" to="a.sel" /> <!-- yes, I changed the name --> <selector id="sel"> <and> <selector refid="a.sel" /> <contains text="foo" /> </and> </selector> Is there another way, without code (I know, code is not necessarily the most evil thing in the world...)?
Hmmm, I'm not fond of this notation. I see where you are going with this, and it would indeed solve the problem at hand, and even the problem generally, but it's still kinda ugly and hacky to me. This all boils down to me to the lack of compartimentation of references in the context of import. We introduced compartimentation of target by allowing to reference them using the <project name>.<ref name> composed name, and allowing silent override of imported targets. (FTR, I was against using <project name>. and would have preferred using a build-specific private name to refer to imported build file artifacts) Having of compartimentation of references in the context of import would avoid the need of <refcopy> I think, as you could always refer to an imported reference thru its composed name, and override (hopefully silently) the non-composed name with the new definition. Am I making sense? --DD --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
