Hmm... Antunit seems to be giving me bogus results. It should fail,
but it doesn't. Try the following build file. First try running the
default target, "main", under either Ant-1.6.5 or Ant-1.7.0. Notice
that the property for ${app.m} remains unresolved and ends up as the
literal value "${app.n}". This is the bug I've been discussing in
this thread, and is what I expect until the XMLProperty task is
fixed. After a fix is applied, the expected value should be "n".
Now try running the "antunit" target (Under Ant-1.7.0+). We've
already seen (above) that the value for ${app.m} doesn't resolve to
the value "n" as it should. However, Antunit doesn't report
failure. The property is resolved in Antunit's world. Change the
expected value for any of the tests to something other than "n" and
it does fail, so, Antunit is clearly actively testing. How did
${app.m} get resolved to the value "n" in the Antunit assertions, but
not when I echo'd it when running the non-Antunit "main" target? Is
Antunit re-resolving values that look like property declarations? I
like the idea of Antunit, but there's clearly something left to be
desired in its current implementation. Did I find yet another bug in
Ant-related software or am I missing something???
Anyway, here's the test build....
<project name="test.xmlproperties" default="main"
xmlns="antlib:org.apache.tools.ant" xmlns:au="antlib:org.apache.ant.antunit">
<target name="main" depends="setUp, mainImpl, tearDown"/>
<target name="mainImpl">
<echo>
app.n=${app.n}
app.o=${app.o}
app.m=${app.m}
</echo>
</target>
<target name="antunit">
<au:antunit>
<fileset file="${ant.file.test.xmlproperties}"/>
<au:plainlistener/>
</au:antunit>
</target>
<target name="setUp">
<property name="xmlproperties.file" location="test.xmlproperties"/>
<echo file="${xmlproperties.file}">
<root-tag>
<app
n="n"
o="${app.n}"
m="${app.n}"/>
</root-tag>
</echo>
<xmlproperty
file="${xmlproperties.file}"
collapseAttributes="true"
keepRoot="false"
semanticAttributes="true"/>
</target>
<target name="tearDown">
<delete file="${xmlproperties.file}"/>
</target>
<target name="testXMLPropertiesIntraElementAttributePropertyResolution">
<au:assertFileExists file="${xmlproperties.file}"/>
<au:assertPropertyEquals name="app.n" value="n"/>
<au:assertPropertyEquals name="app.o" value="n"/>
<au:assertPropertyEquals name="app.m" value="n"/>
<au:assertEquals actual="${app.n}" expected="n"/>
<au:assertEquals actual="${app.o}" expected="n"/>
<au:assertEquals actual="${app.m}" expected="n"/>
</target>
</project>
Jake
At 09:48 AM 1/17/2007, you wrote:
>Quoting Steve Loughran <[EMAIL PROTECTED]>:
>
>> Jacob Kjome wrote:
>> > Quoting Steve Loughran <[EMAIL PROTECTED]>:
>>
>> >
>> > No, I get the same behavior in Ant-1.6.5. I think this is a longstanding
>> issue.
>>
>> uh oh. those are bad. Theres more of a risk that someone has been
>> depending on it.
>>
>
>Except, in this case, I would think that it would have made people
avoid trying
>to use it because it wouldn't have worked for them, unless they wanted a the
>resulting property value to be the literal referencing property
declaration. I
>find that unlikely. More likely, users seldom refer to an attribute from
>another attribute in the same element and, if they attempt it, they find that
>it doesn't work and probably use the nested element workaround.
>
>> >
>> >> 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.
>>
>> file it as a defect, one with an Antunit test case that we can drop into
>> the codebase. That way we can add the bug to the tree and the tests
>> failing will remind us to fix.
>>
>
>Antunit, eh? I'll have to read up on that first. I'll try to
create the issue
>sometime tonight.
>
>
>Jake
>
>>
>>
>> -steve
>>
>
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: [EMAIL PROTECTED]
>For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
