Quoting Steve Loughran <[EMAIL PROTECTED]>:
> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]