Jacob Kjome wrote:
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???
<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>
You could use <echoxml> to do that without the escaping, though it can
mangle namespaces. I just added a new XML file in the repository
<target name="testInlineExpansion">
<xmlproperty
file="xmlproperty.inline-expansion.xml"
collapseAttributes="true"
keepRoot="false"
semanticAttributes="true"/>
<echo>
element expected actual
p ${app.n} ${app.p}
n n ${app.n}
o n ${app.o}
m n ${app.m}
</echo>
<au:assertPropertyEquals name="app.p" value="${app.n}"/>
<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>
~/Java/Apache/ant/src/tests/antunit/taskdefs> ant -f
xmlproperty-test.xml testInlineExpansion
testInlineExpansion:
[echo]
[echo] element expected actual
[echo] p n n
[echo] n n n
[echo] o n n
[echo] m n ${app.n}
[echo]
BUILD SUCCESSFUL - at 18/01/07 10:26
Which means
1 . yes, I see your behaviour. Attributes are evaluated in alpha order,
not file order. Its possible this is happening somewhere in the XML
processing code in ant, not in the xmlproperty task.
2. I dont see the assertions working. Its not the antunit runner, as you
can see the same effect on the command line.
(pause)
OK. I think I see the problem. There must be some property expansion
going on inside the assertion macros. so the ${app.n} is being expanded
to n inside them, which is resulting in the matching working.
New test:
<property name="sequence" value="${app.m}${app.n}${app.o}${app.p}"/>
<fail>
xml attributes are not expanding correctly
expected: mnop=nnn$${app.n}
actual mnop=${sequence}
<condition>
<not>
<equals arg1="${sequence}" arg2="nnn${app.n}"/>
</not>
</condition>
</fail>
This breaks correctly; checked in inside xmlproperty-test.xml, so
everyone's test build now breaks
-steve
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
