Mailing-List: contact dev-help@ant.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Ant Developers List" <dev@ant.apache.org>
Received-SPF: pass (nike.apache.org: domain of jak-ant-dev@m.gmane.org
 designates 80.91.229.3 as permitted sender)
To: dev@ant.apache.org
From: Jesse Glick <jesse.glick@oracle.com>
Subject: Re: Property expansion in macrodef attributes
Date: Tue, 14 Feb 2012 09:29:03 -0500
Organization: Oracle Corp. / NetBeans
Lines: 17
Message-ID: <jhdr3g$2o3$1@dough.gmane.org>
References: <87aa4oqs0d.fsf@v35516.1blu.de> <jh9300$9ds$1@dough.gmane.org>
 <87vcn9zj0y.fsf@v35516.1blu.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
 rv:9.0) Gecko/20111229 Thunderbird/9.0
In-Reply-To: <87vcn9zj0y.fsf@v35516.1blu.de>

On 02/14/2012 07:39 AM, Stefan Bodewig wrote:
> Most likely you don't want double expansion in most cases.

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.

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

True; so release a new AntUnit - a much smaller user audience than Ant itself I suppose.

> add the attribute to trunk but make trunk's behavior
> default to not expand ${} twice (flagging it as breaking BWC)

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 advance, since the attribute would be rejected by 1.8.x.


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