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]