Stefan Bodewig wrote:
Should there be an entry in WHATSNEW, and updates to the manual?
Absolutely. Unfortunately I'm pretty much maxed out for the next few
weeks and struggle to get some open source coding time.
I can try to document it then.
---
On 2009-11-04, Jesse Glick wrote:
> So it looks like all this is now implemented
Yep, including tests.
> Should there be an entry in WHATSNEW, and updates to the manual?
Absolutely. Unfortunately I'm pretty much maxed out for the next few
weeks and struggle to get some open source coding time
Stefan Bodewig wrote:
2. Introduce Project.isTrueOrSet(String val) which would return true
if toBoolean(val) || getProperty(val) != null.
PropertyHelper likely is the better place for this, otherwise I agree,
the code has to move out of Target and needs the described semantics. [...]
3. Call
On 2009-09-25, Jesse Glick wrote:
> Refined proposal:
> 1. Make evaluate if/unless attributes (just before deciding
> whether or not to run the target).
it already does (and has done so in the past).
> 2. Introduce Project.isTrueOrSet(String val) which would return true
> if toBoolean(val) ||
--- On Fri, 9/25/09, Dominique Devienne wrote:
> From: Dominique Devienne
> Subject: Re: if/unless Attributes
> To: "Ant Developers List"
> Date: Friday, September 25, 2009, 9:31 AM
> On Fri, Sep 25, 2009 at 8:16 AM,
> Jesse Glick
> wrote:
> > Refined p
On Fri, Sep 25, 2009 at 8:16 AM, Jesse Glick wrote:
> Refined proposal:
>
> 1. Make 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.
>
Stefan Bodewig wrote:
A modest suggestion: why don't we just make PropertyHelper treat
(String) "false" as (Boolean) false, and 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
On 2009-09-24, Matt Benson wrote:
> --- On Thu, 9/24/09, Peter Reilly wrote:
>> using
>> seems to be very very strange..
> Maybe it seems that way, but taking into account you'd have to be
> deliberately using propertyhelper delegates to make proper use of
> this, it might look like:
>
>
--- On Thu, 9/24/09, Peter Reilly wrote:
> From: Peter Reilly
> Subject: Re: if/unless Attributes
> To: "Ant Developers List"
> Date: Thursday, September 24, 2009, 12:36 PM
> using if="${foo}">
> seems to be very very strange..
>
Maybe it seems
--- On Thu, 9/24/09, Dominique Devienne wrote:
> From: Dominique Devienne
> Subject: Re: if/unless Attributes
> To: "Ant Developers List"
> Date: Thursday, September 24, 2009, 12:15 PM
> On Thu, Sep 24, 2009 at 10:46 AM,
> Stefan Bodewig
> wrote:
> &
using
seems to be very very strange..
Peter
On Thu, Sep 24, 2009 at 5:09 PM, Stefan Bodewig wrote:
> On 2009-09-24, Stefan Bodewig wrote:
>
>>
>
>> 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 somethi
On Thu, Sep 24, 2009 at 10:46 AM, Stefan Bodewig wrote:
> On 2009-09-24, Dominique Devienne wrote:
>> we have ${toString:foo}, we might as well call it ${toBoolean:foo} to
>> be consistent,
>
> toString applies to project references, not properties, so they would
> not be as symmetric as they loo
On 2009-09-24, Stefan Bodewig wrote:
>
> 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).
This part is false, I just re-read the code. It will look up a
On 2009-09-24, Jesse Glick wrote:
> Stefan Bodewig wrote:
>> I don't see an easy way to [make 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 t
On 2009-09-24, Dominique Devienne wrote:
> we have ${toString:foo}, we might as well call it ${toBoolean:foo} to
> be consistent,
toString applies to project references, not properties, so they would
not be as symmetric as they look.
Stefan
-
On 2009-09-24, Matt Benson wrote:
> Along these lines, I was just in the process of coding up a
> BooleanEvaluator for the props antlib--I was just thinking
> e.g. ${boolean:on} and delegate to Project.toBoolean(String). If used
> in conjunction with the NestedPropertyExpander, ${boolean:${foo}}
--- On Thu, 9/24/09, Stefan Bodewig wrote:
> From: Stefan Bodewig
> Subject: Re: if/unless Attributes
> To: dev@ant.apache.org
> Date: Thursday, September 24, 2009, 10:42 AM
> On 2009-09-24, Dominique Devienne
>
> wrote:
>
> > On Thu, Sep 24, 2009 at 6:
On 2009-09-24, Dominique Devienne wrote:
> On Thu, Sep 24, 2009 at 6:32 AM, Stefan Bodewig wrote:
>> the if/unless attributes for target have changes slightly in that they
>> now may use PropertyHelpers. I.e.
>>
>> will not be executed if ${foo} happens to expand to a Boolean instance
>> wit
--- On Thu, 9/24/09, Dominique Devienne wrote:
> From: Dominique Devienne
> Subject: Re: if/unless Attributes
> To: "Ant Developers List"
> Date: Thursday, September 24, 2009, 9:12 AM
> On Thu, Sep 24, 2009 at 9:04 AM, Matt
> Benson
> wrote:
> >> An
Stefan Bodewig wrote:
I don't see an easy way to [make 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 => St
On Thu, Sep 24, 2009 at 6:32 AM, Stefan Bodewig wrote:
> the if/unless attributes for target have changes slightly in that they
> now may use PropertyHelpers. I.e.
>
>
>
> will not be executed if ${foo} happens to expand to a Boolean instance
> with a booleanValue() of "false" and likewise
>
>
On Thu, Sep 24, 2009 at 9:04 AM, Matt Benson wrote:
>> And a related question: 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? Or sho
--- On Thu, 9/24/09, Stefan Bodewig wrote:
> From: Stefan Bodewig
> Subject: if/unless Attributes
> To: dev@ant.apache.org
> Date: Thursday, September 24, 2009, 6:32 AM
> Hi,
>
> the if/unless attributes for target have changes slightly
> in that they
> now may use PropertyHelpers. I.e.
>
>
23 matches
Mail list logo
