ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From peter reilly <peter.rei...@corvil.com>
Subject Re: cvs commit: ant/src/main/org/apache/tools/ant/taskdefs/optional/junit FormatterElement.java JUnitTask.java
Date Wed, 28 May 2003 17:21:27 GMT
I would rather use the "C" logic for this.
Unless the value is explicity "false/off/no" or "",
the value is treated as true.

This would break less scripts. But it is still
not bc and third party tasks would also need
to be changed to follow the new behaviour.

Peter.

On Wednesday 28 May 2003 17:37, Steve Loughran wrote:
> 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
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> For additional commands, e-mail: dev-help@ant.apache.org


Mime
View raw message