ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bruce Atherton <br...@callenish.com>
Subject Re: cvs commit: ant/src/main/org/apache/tools/ant/taskdefs/optional/junit FormatterElement.java JUnitTask.java
Date Thu, 29 May 2003 03:05:55 GMT
At 09:37 AM 5/28/2003 -0700, Steve Loughran wrote:
>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.

Ditto. Generally, I favour usefulness over a theoretical, unimplemented 
design so given a valid use case I think keeping the change is a good idea, 
unless people want to talk about implementing a redesign to address the 
general trend more cleanly.


>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

If we wanted to do this, shouldn't we use attributes other than "if" or 
"unless", for backwards compatibility? "iftrue" and "unlesstrue" would be 
ugly choices, but you get the idea. We could deemphasize "if" and "unless" 
in the documentation since people find them confusing.

Or we could redirect the problem a little. How about a "condition" 
attribute that is a reference to an existing condition at the top level? 
The property that is set if the condition is true when called in this way 
could be a special internal one for use only by the element with the 
condition attribute, hidden from the user. So whether it is tested as 
set/unset or true/not-true would be irrelevant to the end user.



Mime
View raw message