Hi all,
for those who don't follow bugzilla comment threads (I know I seldomly
do):
Until Ant 1.8.2 ${} sequences in macrodef attributes were expanded once
before @{} sequences are expanded and once in the context where the @{}
is expanded. I.e. with
<macrodef name="propertycopy">
<attribute name="name"/>
<attribute name="from"/>
<sequential>
<property name="@{name}" value="${@{from}}"/>
</sequential>
</macrodef>
<property name="choice" value="2"/>
<property name="thing.1" value="one"/>
<property name="thing.2" value="two"/>
<property name="thing.3" value="three"/>
<propertycopy to="thing" from="thing.${choice}"/>
@{from} becomes thing.2 and the second expansion does what the FAQ says.
Ant's trunk has removed the ${} expansion that happens before @{}
expansion, breaking the example of our own FAQ and breaking some other
existing macrodefs out there (for example in Netbeans).
https://issues.apache.org/bugzilla/show_bug.cgi?id=52621
Double expansion is unexpected and leads to subtle issues:
https://issues.apache.org/bugzilla/show_bug.cgi?id=42046
https://issues.apache.org/bugzilla/show_bug.cgi?id=41400
In particular it made some AntUnit tests pass in Ant's own code base
even though the code was actually broken.
Jesse suggests to introduce an attribute to macrodef (or even at the
granularity of the individual attribute definition of a macrodef) to
control ${} expansion.
I'm not sure whether the macrodef writer will always know whether she
wants double-expansion or not. I also fear it will be quite difficult
to explain in the manual of a macrodefed task ("this attribute may have
${} sequences expanded twice, this other one will not").
Another option would be to not fix the 1.8.2 behavior at all but call it
a feature. Macrodef writers then can say something like "foo is
implemented as a macrodef so ${} will be expanded twice, see
http://ant.apache.org/faq.html#macrodef-property-expansion - not sure
whether this a good option.
Any other ideas?
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
[Ant-dev] Property expansion in macrodef attributes
| Tweet |
|
Search Discussions
Discussion Posts
Follow ups
- Jesse Glick: I would say that if you come across a problem like that mentioned in #42046 then you know you do not want double expansion and should explicitly turn it off. In most cases the script calling the macro will be the same as the script defining it, or at least located in the same project, so I doubt documentation of the macrodef is an issue; though discoverability of the flag in the macrodef task may be poor even with a FAQ entry. If this problem had been noticed when macrodef was first introduced,
- Stefan Bodewig: The biggest problem I see is AntUnit. Here the macro is defined in a different place and we'd need a new release that requires Ant 1.8.3 to fix it. Right now I'm inclined to revert to the behavior of Ant 1.8.2 for the 1.8.x branch, add the attribute to trunk but make trunk's behavior default to not expand ${} twice (flagging it as breaking BWC). I'm with Matt in that property helpers already provide the foundation for a solution and the props Antlib (anybody wants to cut a release?) implements
- Jesse Glick: Right, but how often would you even notice the difference? Usually property values do not themselves contain interpolable variables, as seen by the fact that this problem has just been reported twice since macrodef was introduced. This would cause a major problem for the many scripts out there which rely on the current behavior. They could not run unchanged on 1.9 (and few people will find this item in the release notes, much less understand its implications); nor could they be fixed in
Related Discussions
Discussion Overview
| group | dev
 |
| categories | ant |
| posted | Feb 12, '12 at 10:13a |
| active | Feb 25, '12 at 5:18p |
| posts | 9 |
| users | 2 |
| website | ant.apache.org |
2 users in discussion
