Bug 41400

Summary: [PATCH] properties get double expanded in <assertPropertyEquals>
Product: Ant Reporter: Steve Loughran <stevel>
Component: CoreAssignee: Ant Notifications List <notifications>
Status: RESOLVED DUPLICATE    
Severity: normal CC: a.broekhuis, machisuji, vladimir_egorov
Priority: P2 Keywords: PatchAvailable
Version: 1.7.0   
Target Milestone: ---   
Hardware: Other   
OS: other   
Attachments: Fixed double property expansion in macrodefs.

Description Steve Loughran 2007-01-18 04:17:43 UTC
While trying to track down why the antunit tests for the xml-attribute-expansion
wasnt working, I came to the conclusion that properties get expanded in the process.

that is, ifyou have
<property name="one" value="1" />
<property name="prop" value="$${one}" />
  (so that prop==${one})
when you test the value, you get a match against the contents of ${one}
<au:assertPropertyEquals property name="prop" value="1" />

Possibly more of a general purpose macro problem than anything else.
Comment 1 Vladimir Egorov 2007-04-04 08:05:37 UTC
As mentioned above, this is a generic macrodef problem (back in 1.6.5)
http://issues.apache.org/bugzilla/show_bug.cgi?id=42046
Comment 2 Markus Kahl 2009-12-30 11:36:03 UTC
Created attachment 24783 [details]
Fixed double property expansion in macrodefs.

With this patch the assertion fails as expected,
because the property is not expanded twice anymore.
Comment 3 Markus Kahl 2009-12-30 11:38:37 UTC
Bug fixed by attached patch.
Comment 4 Matt Benson 2010-01-03 09:03:13 UTC
(Reopening to avoid loss)
Comment 5 Stefan Bodewig 2010-01-04 21:14:54 UTC
*** Bug 42046 has been marked as a duplicate of this bug. ***
Comment 6 Stefan Bodewig 2010-01-04 22:00:18 UTC
After applying the patch one of Ant's tests (propertyhelper-test, testLoadProperties) fails:

Expected property 'object2' to have value 'java.lang.Object@178acba' but was 'java.lang.Object@178acba'
at line 124 , column 65

and it is not obvious to me where the current test relies on double expansion.  The problem may as well be inside AntUnit.

Given that we are only days away from Ant 1.8.0, I'd prefer to defer looking into it until Ant 1.8.1.
Comment 7 Markus Kahl 2010-01-04 22:51:34 UTC
(In reply to comment #6)
> After applying the patch one of Ant's tests (propertyhelper-test,
> testLoadProperties) fails:
> 
> Expected property 'object2' to have value 'java.lang.Object@178acba' but was
> 'java.lang.Object@178acba'
> at line 124 , column 65
> 
> and it is not obvious to me where the current test relies on double expansion. 
> The problem may as well be inside AntUnit.
> 
> Given that we are only days away from Ant 1.8.0, I'd prefer to defer looking
> into it until Ant 1.8.1.

Sorry that I haven't run the tests before even sending in the patch.
I still couldn't get the tests running because for some reason junit.framework.TestCase isn't found and so all the tests fail.

JUnit is definitely in the classpath, though. :/


I recognize that error message. When I tried to fix the bug first I made
a change directly in MacroInstance.java which was rather a hack to see what was happening.
When a return value in macroSubs() started with $ I just added another one. :D
The result were error messages like that one you got.
That is during the comparison of the values the property wasn't double-expanded but then again in the output, I think.
Comment 8 Stefan Bodewig 2010-01-05 21:11:33 UTC
First of all, thank you for the patch, Markus - no need to apologize.

The best way to run Ant's tests (IMHO) is to put junit.jar into lib/optional in Ant's source tree and run "./build.sh test".

Making the code avoid the double expansion inside of MacroInstance may be cleaner but I doubt it can be done without help from UnknownElement or RuntimeConfigurable, we'll see.

From the error message (the only one I've seen, BTW) it looks as if the two objects actually are the same but <equals> would fail to see that.
Comment 9 Markus Kahl 2010-01-17 08:50:31 UTC
I now managed to run the tests on a linux machine. On windows dozens of tests failed because some files could not be deleted or something.
Anyway, in revision 900143 the propertyhelper-tests does not fail.

Actually my patch does not break any tests anymore.
The same tests failed before and after my patch.

Now given the following file:

<project name="Macros" default="testBug" basedir="." 
	xmlns:au="antlib:org.apache.ant.antunit">
  <property name="one" value="1"/>
  <property name="prop" value="$${one}"/>

  <macrodef name="echotest">
    <attribute name="message" />
    <sequential>
      <echo message="@{message}" />
    </sequential>
  </macrodef>

  <target name="testBug">
	<echo message="$${builddir}" />
	<echotest message="$${builddir}"/>
	<au:assertPropertyEquals name="prop" value="1"/>
  </target>
</project>

After the patch I get the following output:

markus@Bunker-12:~$ ant -f macros.xml
Buildfile: /home/markus/macros.xml

testBug:
     [echo] ${builddir}
     [echo] ${builddir}

BUILD FAILED
/home/markus/macros.xml:16: Expected property 'prop' to have value '1' but was '${one}'

What puzzles me is that the output from testBug is also correct without my patch. It wasn't earlier (bug #42046), though.
I wonder if it only works because of a 'workaround' or 'by accident'.

I got to take a look into the source of AntUnit, I thought au:assertPropertyEquals was also simply a macrodef.
Comment 10 Markus Kahl 2010-01-17 08:57:31 UTC
Damn it I'm sorry. ^^
As you already said in response to my comment on bug #42046
you could still reproduce that bug.
I couldn't, but only because I wrote ${BUILDdir} insetad of ${BASEdir} ...
My bad. *facepalm*

Now that this is clear, my comment above boils down to this:

My patch doesn't seem to break any tests in revision 900143, which should be the latest as of now.
Comment 11 Alexander Broekhuis 2010-12-07 04:44:14 UTC
Hello,

I was wondering what the state is of this bug. When will it be released in an ant version, and which version will this be?

TiA!
Comment 12 Greg 2011-09-08 16:36:41 UTC
Just hit this bug in 1.8.2. Nasty in my case as the variable being expanded was sometimes defined and sometimes not, making it very hard to track down.

Any chance this patch will be included in a future release?
Comment 13 Stefan Bodewig 2011-11-17 16:10:10 UTC

*** This bug has been marked as a duplicate of bug 42046 ***