ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Loughran <>
Subject Re: <xmlproperty> intra-element attribute property resolution issue
Date Thu, 18 Jan 2007 10:59:43 GMT
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}">
> &lt;root-tag&gt;
>   &lt;app
>     n="n"
>     o="${app.n}"
>     m="${app.n}"/&gt;
> &lt;/root-tag&gt;
>         </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">
  element      expected    actual
     p         ${app.n}    ${app.p}
     n            n        ${app.n}
     o            n        ${app.o}
     m            n        ${app.m}
     <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"/>

~/Java/Apache/ant/src/tests/antunit/taskdefs> ant -f 
xmlproperty-test.xml testInlineExpansion

      [echo]  element      expected    actual
      [echo]     p         n    n
      [echo]     n            n        n
      [echo]     o            n        n
      [echo]     m            n        ${app.n}

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.


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}"/>
       xml attributes are not expanding correctly
       expected: mnop=nnn$${app.n}
       actual    mnop=${sequence}
           <equals arg1="${sequence}" arg2="nnn${app.n}"/>

This breaks correctly; checked in inside xmlproperty-test.xml, so 
everyone's test build now breaks


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message