>isolation between the calling and thecalled project.
stefan, it is true of inherit* properties, however here are some scenarios
1. The developers may want to call clean, startTomcat... etc and some other
targets from root to all the sub directories. However module developers are
more intereste
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 2009-09-25, Raja Nagendra Kumar wrote:
> Currently I see is launching new ant even if the build file is same
> as the current one being executed.
A new Project instance, but not a new process.
> Would it not be more fast to excute the target in the current ant process it
> self, provided bu
Hi,
Currently I see is launching new ant even if the build file is same
as the current one being executed.
Would it not be more fast to excute the target in the current ant process it
self, provided build file and directory are same.
Regards,
Nagendra
--
View this message in context:
http://
--- 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 that way, but taking into account you'd have
--- 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:
> > On 2009-09-24, Dominique Devienne
> wrot
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:32 AM, Stefan Bodewig
> wrote:
> >> th
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:
> >> And a related question: we currently don't pr
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.
>
>
ano.com.au
__ Information from ESET NOD32 Antivirus, version of virus signature
database 4453 (20090924) __
The message was checked by ESET NOD32 Antivirus.
http://www.eset.com
patch.tar.gz
Description: GNU Zip compr
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 hasn't been documente
21 matches
Mail list logo
