ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jesse Glick <>
Subject Re: if/unless Attributes
Date Fri, 25 Sep 2009 13:16:52 GMT
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:
For additional commands, e-mail:

View raw message