--- Dominique Devienne <[EMAIL PROTECTED]> wrote: > > <!-- > > 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
Yup. It does indeed seem sensible to handle imported refs like imported targets. Probably a little more complicated than the alternative though. I wonder if it's doable in the (tiny) 1.7 timeframe. -Matt > > --------------------------------------------------------------------- > To unsubscribe, e-mail: > [EMAIL PROTECTED] > For additional commands, e-mail: > [EMAIL PROTECTED] > > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
