ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dominique Devienne" <ddevie...@gmail.com>
Subject Re: copying references
Date Thu, 31 Aug 2006 15:50:52 GMT
>  <!--
>  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: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org


Mime
View raw message