Stefan Bodewig wrote:
I don't see an easy way to [make <fail> work] since the Strings sent
to the attributes of tasks and types are property expanded (unlike the
attributes of target) and in the case I've described the tasks won't see
${foo} anymore but the String "false" (via the implicit Object => String
conversion of PropertyHelper)
[...]
we currently don't provide any PropertyEvaluator
that would create Booleans. Do we want to provide something like
${isTrue:foo} that created Boolean.TRUE if Project.toBoolean(${foo}) was
true?
A modest suggestion: why don't we just make PropertyHelper treat (String) "false" as (Boolean) false, and <target> likewise? Then we would not need any new magical
evaluators and most people would never need to use the <istrue> condition. Passing -DdoSomething=false would actually do what every developer new to Ant expects it to do
(as opposed to Ant's current behavior which is quite surprising and inconvenient).
Maybe this is a bit too Perlish for some people, but Ant already forces you to stringify properties and that's what build scripts (and their *.properties configuration)
are expecting.
For the three scripts out there which intentionally rely on "false" being true, the old behavior could be reenabled with a compatibility property set on the project which
would issue warnings when it needed to be used. Any such scripts could easily be made to avoid this assumption (while retaining 1.7.x compatibility):
<target name="run" if="doSomething">
<echo>runs even if -DdoSomething=false!</echo>
</target>
=>
<condition property="doSomething.set"><isset
property="doSomething"/></condition>
<target name="run" if="doSomething.set">
<echo>still runs with -DdoSomething=false but now more obvious</echo>
</target>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org
