ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jacob Kjome <h...@visi.com>
Subject Re: <xmlproperty> intra-element attribute property resolution issue
Date Thu, 18 Jan 2007 06:14:24 GMT

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}">
&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>

     <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 <stevel@apache.org>:
 >
 >> Jacob Kjome wrote:
 >> > Quoting Steve Loughran <stevel@apache.org>:
 >>
 >> >
 >> > 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: user-unsubscribe@ant.apache.org
 >For additional commands, e-mail: user-help@ant.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@ant.apache.org
For additional commands, e-mail: user-help@ant.apache.org


Mime
View raw message