On 2009-09-24, Jesse Glick <jesse.gl...@sun.com> wrote:
> 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?
I wouldn't do that in PropertyHelper, but would think it may be a
sensible choice for target.
One thing to note (at least of the current implementation) is that there
is a difference between the is-set? and is-true? logic in these
attributes:
<target if="foo"/>
will only be executed if a property named foo exists, regardless of its
value. This is the same for Ant 1.8.0 and 1.7.1.
<target if="${foo}"/>
will only be executed if a property named ${foo} exists (unexpanded) -
in Ant 1.7.1. and Ant 1.8.0 - or if expanding ${foo} returns something
that equals Boolean.TRUE (Ant 1.8.0 only).
As soon as we talk about task/type attributes things change since these
attributes are always subject to property expansion.
<fail if="foo"/> has the same semantics as <target if="foo"/> but for
<fail if="${foo}"/> ${foo} gets expanded when looking up the property
name (this difference has been ever since <target> and <include> both
had if attributes, don't remember which came first).
Back to your suggestion
> 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).
No it wouldn't since
<target if="doSomething"/>
still wouldn't expand the property, you'd have to write
<target if="${doSomething}"/>
instead.
By tweaking the implementation of Target#testIfAllows to use getProperty
instead of parseProperties when testing for the Boolean this would work,
but it would be the only place in Ant where properties get expanded
without using the ${} syntax.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org
