ant-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject DO NOT REPLY [Bug 42046] properties get double-expanded in macrodefs
Date Sun, 12 Feb 2012 08:22:04 GMT

--- Comment #9 from Stefan Bodewig <> 2012-02-12 08:22:04 UTC ---
The current patch in trunk only applies to the attributes of the macro
invocation, nested text or nested elements are not directly affected.  For
nested text this doesn't pose any problem as Ant's engine doesn't expand
properties there, the task has to do it, so there is no double-expansion. 
Nested elements aren't handled in RuntimeConfigurable directly but rather when
the nested sequential of the MacroInstance is configured.

What happened before the patch is Ant expanded properties of the attributes of
each echotest instance before calling execute on the MacroDef instance backing
it, then the MacroInstance created a new UnknownElement for the sequential
defined inside the macrodef, replaced @{...} sequences while creating it and
the handed it off to Ant's engine to configure - which led to another round of
property expansions.

So properties in attributes are expanded in trunk as well, it is only that they
are only expanded once rather than twice (which is needed for the macrodef from to work).

It boils down to "is ${} expansion performed before and after @{} expansion or
only after @{} expansion".  I agree the default has to be "before and after" to
avoid regressions.

With an attribute like Jesse suggests we end with a subtle difference that not
only is hard to explain for the macrodef manual but also requires macrodef
writers to document for their users (who don't necessarily know they are using
a macrodef in the first place).  Something like "properties used in the message
attribute might get expanded twice so you must use three $ characters rather
than two to avoid expanding a property reference".  The same is true for any
macrodef used with Ant 1.8.2 and earlier anyway.

I can't say I'm satisfied with the proposed solution but don't see any
alternative.  The only other option I see is not fixing this bug but calling it
a feature and document it properly (which still leaves macrodef writers to
explain the behavior of their tasks to their users).

I'm going to add a FAQ entry documenting the current behavior in the first

Configure bugmail:
------- You are receiving this mail because: -------
You are the assignee for the bug.

View raw message