ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jacob Kjome <h...@visi.com>
Subject Re: <xmlproperty> intra-element attribute property resolution issue
Date Tue, 16 Jan 2007 23:35:25 GMT
Quoting Steve Loughran <stevel@apache.org>:

> 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.
>

No, I get the same behavior in Ant-1.6.5.  I think this is a longstanding issue.

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

I thought you might say that.  I was hoping more for a "yeah, the Ant team will
get it fixed for Ant-1.7.1", but so goes Open Source.  We'll see if I get time.
 In the meantime, I hope someone on the Ant team already familiar with the
XMLProperty task can look at this.

Jake

> -steve




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


Mime
View raw message