ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Loughran <stev...@iseran.com>
Subject Re: cvs commit: ant/src/main/org/apache/tools/ant/taskdefs/optional/junit FormatterElement.java JUnitTask.java
Date Wed, 28 May 2003 16:37:28 GMT
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




Mime
View raw message