Stefan Bodewig wrote:
A modest suggestion: why don't we just make PropertyHelper treat
(String) "false" as (Boolean) false, and <target> likewise?
I wouldn't do that in PropertyHelper
Sorry, what I wrote did not make sense.
but would think it may be a sensible choice for target.
What I meant was for if/unless on <target> and any tasks or types or subelements like
<fail>, <include>, etc. which have a similar attribute pair.
<target if="doSomething"/>
still wouldn't expand the property, you'd have to write
<target if="${doSomething}"/>
instead.
Which is more intuitive anyway; people are accustomed to always writing uses of properties with ${...} and it is confusing to have to omit the expansion only in this
handful of cases.
Refined proposal:
1. Make <target> evaluate if/unless attributes (just before deciding whether or
not to run the target).
2. Introduce Project.isTrueOrSet(String val) which would return true if
toBoolean(val) || getProperty(val) != null.
3. Call iTOS from <target>, <fail>, etc. - anything with if/unless attributes
with the standard meaning.
Now <target if="doSomething"> would behave as before, for better or worse. But you could also write <target if="${doSomething}"> and it would work as most novice Ant
users would expect: run the target if doSomething is defined but also set to 'true' (or 'on' or 'yes'). Similarly for <fail> and friends.
Incompatibility would be restricted to some pathological cases such as:
<target if="true"><echo>used to run only if -Dtrue=whatever, now will always
run</echo></target>
<property name="$${weird}" value="whatever"/>
<target if="${weird}"><echo>used to run, now will not unless
-Dweird=true</echo></target>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org
