[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ant-dev
Subject:    Re: Property expansion in macrodef attributes
From:       Stefan Bodewig <bodewig () apache ! org>
Date:       2012-02-25 17:17:53
Message-ID: 871upi7ry6.fsf () v35516 ! 1blu ! de
[Download RAW message or body]

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
time).

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

property-test:

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.

property-helper-test:

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.

Stefan

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

[prev in list] [next in list] [prev in thread] [next in thread]