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.

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.

(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.

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.

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.

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.

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?

This is ASF Bugzilla: the Apache Software Foundation bug system. In case
of problems with the functioning of ASF Bugzilla, please contact
bugzilla-admin@apache.org.
Please Note: this e-mail address is only for reporting problems
with ASF Bugzilla. Mail about any other subject will be silently
ignored.