https://issues.apache.org/bugzilla/show_bug.cgi?id=42046
--- Comment #9 from Stefan Bodewig <[email protected]> 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 http://ant.apache.org/faq.html#propertyvalue-as-name-for-property 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 place. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.
