ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jose Alberto Fernandez" <>
Subject Re: cvs commit: jakarta-ant/src/testcases/org/apache/tools/ant/taskdefs
Date Mon, 10 Dec 2001 21:53:21 GMT
From: "Stefan Bodewig" <>

> On 10 Dec 2001, <> wrote:
> >   Allow <ant> and <antcall> to pass references to the subbuilds.
> If you use <ant inheritall="false" />, nothing changes.
> There is a new nested element in <ant> (and <antcall>) named
> <reference> that can be used to identify those data type references
> that you want to pass to a subbuild explicitly, you can also change
> the "id" of that reference for the subbuild on the fly.

Just thinking about the eventual unification of <property> and <datatypes>,
it would be nice if we could use the same "verb" to refer to both
when used as perameters, something like:

    <antcall ...>
      <param name="xyx" refid="" />
    <ant ....>
        <param id="cbs" refid="nbc" />

we already have <param> in <antcall> and I do not think having it in <ant>

will upset anyone. <property> subelements can continue to refer to just the strings.

> If you use <ant inheritall="true" /> (or without that attribute), all
> references will be copied over to the subbuild, unless a reference of
> the same name already exists in the subbuild - i.e. the implicit
> copying will never override references defined in child builds.  We
> could as well remove that bit and stick with explicit copying of
> references, I just wanted to get that functionality in and see whether
> it affects Gump runs.
> On the other side, references explicitly passed down via the nested
> <reference> elements will always override existing values in child
> builds, this mirrors the precedence of nested property elements over
> those defined in subbuilds.

Is this the same behavior like for <property>s? Can we please try to 
unify this behaviors? I mean having half of the things working one way
and the other half working differently does not seem like the correct
thing to do.

If this is too risky, then I would suggest having <datatype> inheritance be driven
by a different attribute like: "inheritrefs='true'" which by default is false.
But if set to true will follow exactly the same rules of overriding as for properties.
We need to get things consistent, guys!

Jose Alberto

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message