ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Loughran <>
Subject Re: <xmlproperty> intra-element attribute property resolution issue
Date Tue, 16 Jan 2007 11:25:28 GMT
Jacob Kjome wrote:
> <xmlproperty> seems to have a problem with resolution of attributes within the
> current element.  It appears to resolve the attributes in alphabetical order. 
> If an attribute refers to the value of another attribute in the same element,
> the one doing the referring must come later in the alphabet, otherwise the
> value won't resolve.
> Here's the minimal XMLProperty file displaying the issue...
> <root-tag>
>   <app
>     n="some value"
>     o="${app.n}"
>     a="${app.n}"/>
> </root-tag>
> Here's a minimal build to test the XMLProperty file above and the properties it
> generates...
> <project name="test.xmlproperties" default="echovalues">
>     <xmlproperty
>         file="test.xmlproperties"
>         collapseAttributes="true"
>         keepRoot="false"
>         semanticAttributes="true"/>
>     <target name="echovalues">
>         <echo>
> app.n=${app.n}
> app.o=${app.o}
> app.a=${app.a}
>         </echo>
>     </target>
> </project>
> Here's the output...
> echovalues:
>      [echo]
>      [echo] app.n=some value
>      [echo] app.o=some value
>      [echo] app.a=${app.n}
>      [echo]
> Notice how ${app.o} resolves, but not ${app.a}.  If 'a' was made to be any
> letter after 'n', then it would resolve it just fine, just like 'o' did.
> Is this a known idiosyncracy of the XMLProperty task?  Is it, possibly, a
> compromise to increase resolution efficiency and reduce overall code complexity
> or is it just a bug?  To me, unless this is called out as a known issue (and
> maybe it is somewhere?), it's a bug.  In any case, this behavior makes
> XMLProperty brittle.  One shouldn't have to worry about the alphabetical order
> of attribute names in relation to what attributes can be referenced and which
> ones we can't.  If it's a bug, can it be corrected for Ant-1.7.1?
> Note that the following XMLProperty file provides a workaround, but the use of
> attributes -vs- nested tags, in this case, should be personal preference, not
> mandatory...

I dont know if there is any formal rule about ordering of things. I know 
between ant1.6 and ant1.7 someone added better handling of duplicate 
elements; what you are seeing  is probably a consequence.

have a look at the source and see if you can find a problem.


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

View raw message