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 Tue, 14 Feb 2012 12:39:09 GMT
On 2012-02-12, Jesse Glick wrote:

> On 02/12/2012 05:13 AM, Stefan Bodewig wrote:

>> I'm not sure whether the macrodef writer will always know whether she
>> wants double-expansion or not.

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

Most likely you don't want double expansion in most cases.

> 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;

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

> 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,
> then single expansion would be the more intuitive behavior, especially
> if #29347 were fixed properly so that ${thing.${choice}} works the way
> people expect it to, but it is too late to change the default behavior
> of macrodef.

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

I also understand Ant users don't like to add more dependencies,
something to keep in mind if we ever want to redesign Ant.


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

View raw message