Re: if/unless Attributes

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. ---

Re: if/unless Attributes

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

Re: if/unless Attributes

. Call iTOS from , , etc. - anything with if/unless attributes with the standard meaning. Sounds good. So it looks like all this is now implemented - nice! Should there be an entry in WHATSNEW, and updates to the manual? - To

Re: if/unless Attributes

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 > i

Re: if/unless Attributes

--- 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

Re: if/unless Attributes

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) || get

Re: if/unless Attributes

operties with ${...} and it is confusing to have to omit the expansion only in this handful of cases. 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 toB

Re: if/unless Attributes

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: > >

Re: if/unless Attributes

--- 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

Re: if/unless Attributes

--- 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: > &

Re: if/unless Attributes

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

Re: if/unless Attributes

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

Re: if/unless Attributes

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

Re: if/unless Attributes

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

Re: if/unless Attributes

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 -

Re: if/unless Attributes

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}}

Re: if/unless Attributes

--- 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:

Re: if/unless Attributes

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 e

Re: if/unless Attributes

--- 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

Re: if/unless Attributes

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

Re: if/unless Attributes

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

Re: if/unless Attributes

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

Re: if/unless Attributes

--- 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 ma

if/unless Attributes

Hi, 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 will be executed in that case. So far this h

DO NOT REPLY [Bug 42522] - Add "if"/"unless" attributes to

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 42522] New: - Add "if"/"unless" attributes to

gzilla/show_bug.cgi?id=42522 Summary: Add "if"/"unless" attributes to Product: Ant Version: 1.7.0 Platform: Other OS/Version: other Status: NEW Severity: normal Priority: P2 Component: Co