Return-Path: <steve_l@iseran.com>
Mailing-List: contact dev-help@ant.apache.org; run by ezmlm
Delivered-To: mailing list dev@ant.apache.org
Received: (qmail 6166 invoked from network); 28 May 2003 16:41:04 -0000
Received: from palrel13.hp.com (156.153.255.238)
  by daedalus.apache.org with SMTP; 28 May 2003 16:41:04 -0000
Received: from klaatu.cv.hp.com (smtp2.cv.hp.com [15.0.200.102])
	by palrel13.hp.com (Postfix) with ESMTP id BEA1B1C00F1F
	for <dev@ant.apache.org>; Wed, 28 May 2003 09:41:00 -0700 (PDT)
Received: from iseran.com (chamonix.dhcp.cv.hp.com [15.87.28.64])
	by klaatu.cv.hp.com (Postfix) with ESMTP id F0A2C2BC12
	for <dev@ant.apache.org>; Wed, 28 May 2003 09:40:55 -0700 (PDT)
Message-ID: <3ED4E5C8.9090009@iseran.com>
Date: Wed, 28 May 2003 09:37:28 -0700
From: Steve Loughran <steve_l@iseran.com>
User-Agent: Mozilla/4.0 (compatible;MSIE 6.0; Windows XP)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Ant Developers List <dev@ant.apache.org>
Subject: Re: cvs commit:
 ant/src/main/org/apache/tools/ant/taskdefs/optional/junit
 FormatterElement.java JUnitTask.java
References: <1BFD9984-9110-11D7-B239-000393A564E6@ehatchersolutions.com>
 <200305290004.58108.conor@cortexebusiness.com.au>
In-Reply-To: <200305290004.58108.conor@cortexebusiness.com.au>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N

Conor MacNeill wrote:

>On Wed, 28 May 2003 11:27 pm, Erik Hatcher wrote:
>  
>
>>If folks feel strongly about it, I'll revert it.
>>
>>    
>>
>
>I'm not into strong feelings :-). Let's see what people think.
>
>Conor
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
>For additional commands, e-mail: dev-help@ant.apache.org
>
>  
>
Im ok with this, but do worry about the general trend which I have 
recently contributed to (if and unless on <define> in <csc> and 
siblings, though this is, as with <cc> a mapping of conditional java 
properties to #define values. I also worry about failonerror ... having 
a single try/catch mechanism would seem a better approach there.

On the subject of if/unless, what if we modified the tests to not just 
take the name of a property, but take any of the values of true either 
in the string itself

<property name="foo" value="true">
<property name="nofoo" value="false">

today
if="foo" and if="nofoo" would both eval to true.

but if we looked at the string for true/on/yes then

if="${foo}" => true
if="${nofoo}" =>false

I dont know what this would break (except for people who have properties 
called "true" ), but I can imagine that it would reduce the inordinate 
amount of confusion that if/unless cause people, including me on 
occasions. You those occasions, the one where a conditional string is 
evaluating wrongly and it looks write, but it turns out you were 
${expanding} the property rather than just naming it.

-steve