ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Bodewig <>
Subject Re: Property expansion in macrodef attributes
Date Sat, 25 Feb 2012 17:17:53 GMT
On 2012-02-24, Stefan Bodewig wrote:

> On 2012-02-23, Jesse Glick wrote:

>> On 02/21/2012 10:40 AM, Stefan Bodewig wrote:

>>>> can do the implementation if you agree.

>>> If you can beat me to it, please do.

>> Done in trunk, please review.

> Will do, many thanks.

Merged, I'll build a new release candidate tomorrow morning (European

>> (Especially whether your changes to property-test.xml and
>> propertyhelper-test.xml still stand - I did not understand what was
>> going on with these.)

> I'll try to explain it once I recall the details.


This is a pretty complex setup of property files that are loaded with a
prefix and refer to properties that have been defined previously.  There
is a test that used assertPropertyEquals to assert property bar.y has
the value "y".  In reality the value is "${bar.x}" which when expanded
is "y", here double expansion of the property attribute in
assertPropertyEquals (hidden in the chain of macros that make up this
assertion) was hiding the test actually failed.

The code hasn't been fixed but the test disabled.


We have a custom property helper and want to assert it works by
comparing two different properties set via the same property helper that
always returns the same Object.  assertPropertyEquals is used for the
test and without double expansion we end up comparing the object to the
result of calling toString in the same object (which is false)

Double expansion turned the Object into its string representation before
invoking equals so the test passed.

In both cases I've added alternatives that prove the code is still
broken in the first case or the code works in the second case (by using
strings rather than objects) and IMHO the tests should stay as they are
for now.


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

View raw message