ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Benson <gudnabr...@yahoo.com>
Subject Re: copying references
Date Thu, 31 Aug 2006 16:18:36 GMT
--- Dominique Devienne <ddevienne@gmail.com> 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:
> dev-unsubscribe@ant.apache.org
> For additional commands, e-mail:
> dev-help@ant.apache.org
> 
> 


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org


Mime
View raw message