> From: Matt Benson [mailto:[EMAIL PROTECTED]
>
> --- Jose Alberto Fernandez <[EMAIL PROTECTED]>
> wrote:
> > > From: Magesh Umasankar [mailto:[EMAIL PROTECTED]
> [SNIP]
> > > Easy to provide backwards compatibility here -
> > >
> > >
> [SNIP]
> > I think it is ugly, and there is no reason for
--- Jose Alberto Fernandez <[EMAIL PROTECTED]>
wrote:
> > From: Matt Benson [mailto:[EMAIL PROTECTED]
[SNIP]
So no, having local variables does not give
> us
> > anything we can't do, but it does save us having
> to
> > pollute the Project properties with e.g. 500
> useless properties.
[SNIP]
>
--- Jose Alberto Fernandez <[EMAIL PROTECTED]>
wrote:
> > From: Magesh Umasankar [mailto:[EMAIL PROTECTED]
[SNIP]
> > Easy to provide backwards compatibility here -
> >
> >
[SNIP]
> I think it is ugly, and there is no reason for
> modifying
> when you could just as well define a diferent task,
> From: Magesh Umasankar [mailto:[EMAIL PROTECTED]
>
> From: "Jose Alberto Fernandez"
> Date: 2004-06-24 11:30:33
>
> > But you are changing the contract of .
>
> Easy to provide backwards compatibility here -
>
>
>
> where breakable is false by default.
>
> Similar attributes
From: "Jose Alberto Fernandez"
Date: 2004-06-24 11:30:33
> But you are changing the contract of .
Easy to provide backwards compatibility here -
where breakable is false by default.
Similar attributes may be introduced to other behavior
altering task containers.
Cheers,
Magesh
> From: Magesh Umasankar [mailto:[EMAIL PROTECTED]
>
> From: Matt Benson
> Date: 2004-06-23 17:43:46
>
> > code? So no, having local variables does not give us anything we
> > can't do, but it does save us having to
>
> That is what I was trying to ensure.
>
> > pollute the Proj
> From: Matt Benson [mailto:[EMAIL PROTECTED]
>
> --- Magesh Umasankar <[EMAIL PROTECTED]> wrote:
> > From: Peter Reilly > com>
> > Date: 2004-06-23 16:23:48
> >
> > > are some cases where true local properties would
> > be more easily
> >
> > like...?
> >
>
> like anytime you ha
From: Matt Benson
Date: 2004-06-23 17:43:46
> code? So no, having local variables does not give us
> anything we can't do, but it does save us having to
That is what I was trying to ensure.
> pollute the Project properties with e.g. 500 useless
> properties.
-0. I don't think the
--- Magesh Umasankar <[EMAIL PROTECTED]> wrote:
> From: Matt Benson
> Date: 2004-06-23 15:02:54
>
> > I cringe at the thought of the number of "unique
> > properties" that could be floating about resulting
> > from this...
>
> Is the user community complaining?
[SNIP]
BTW, apparentl
--- Magesh Umasankar <[EMAIL PROTECTED]> wrote:
> From: Peter Reilly com>
> Date: 2004-06-23 16:23:48
>
> > are some cases where true local properties would
> be more easily
>
> like...?
>
like anytime you have to make two passes at some data
to get a property set exactly the way y
Subject:Re: and local
From: Wascally Wabbit
> Why would BreakException subclass from BuildException? It's a
Point taken. So long as it is some sort of RuntimeException, it is
good enough.
> Also as a developer responsible for lots of task container code,
> I'
Why would BreakException subclass from BuildException? It's a
(heavy) flow control mechanism and has nothing to do with error
indication. Just like using try/catch for flow control is not
a good idea, should not piggy back on the build exception
mechanism...
Also as a developer responsible for lot
From: Peter Reilly
Date: 2004-06-23 16:23:48
> are some cases where true local properties would be more easily
like...?
> The task is interesting. I am concerned however about
> how third party task containers would work with it.
If the third-party container would like to support
It is not only with macrodef's that folk want "if/unless", but
macrodef is a bit more obvious because of it's use as a replacement for
used as a sub-routine.
Using constructed property names is a good work-around for
the lack of local properties. But it is a work-around, and there
are some cases w
From: Matt Benson
Date: 2004-06-23 15:02:54
> I cringe at the thought of the number of "unique
> properties" that could be floating about resulting
> from this...
Is the user community complaining? The only issue
that seems to come up every now and then is lack of
straight-forward
> > I think would make the buildscript to a
> > kind of
> > macro language. People (like me :) prefer to hack a
> > macrodef
> > prior to invest more time to implement a real task.
> >
> > And then you´ll need real "variables".
> >
>
> So are you saying you think s should only be
> used as "re
--- [EMAIL PROTECTED] wrote:
> > > > I cringe at the thought of the number of
> "unique
> > > > properties" that could be floating about
> resulting
> > > > from this...
>
> I think would make the buildscript to a
> kind of
> macro language. People (like me :) prefer to hack a
> macrodef
> prior
> > > I cringe at the thought of the number of "unique
> > > properties" that could be floating about resulting
> > > from this...
I think would make the buildscript to a kind of
macro language. People (like me :) prefer to hack a macrodef
prior to invest more time to implement a real task.
And
--- Jose Alberto Fernandez <[EMAIL PROTECTED]>
wrote:
> > From: Matt Benson [mailto:[EMAIL PROTECTED]
> >
> > --- Magesh Umasankar <[EMAIL PROTECTED]> wrote:
[SNIP]
> > > Why do you need them? I typically append an
> > > attribute
> > > value to a property name to get the unique
> property
> > >
> From: Matt Benson [mailto:[EMAIL PROTECTED]
>
> --- Magesh Umasankar <[EMAIL PROTECTED]> wrote:
> > From: Steve Loughran
> > Date: 2004-06-17 9:27:18
> >
> > > I am now convinced we need local properties;
> > without
> > > it macrodef doesnt work fully.
> >
> > Why do you need th
--- Magesh Umasankar <[EMAIL PROTECTED]> wrote:
> From: Steve Loughran
> Date: 2004-06-17 9:27:18
>
> > I am now convinced we need local properties;
> without
> > it macrodef doesnt work fully.
>
> Why do you need them? I typically append an
> attribute
> value to a property name t
-1, I think it is a bad idea
> From: Peter Reilly [mailto:[EMAIL PROTECTED]
>
...
> I see three places where it/unless attributes could be added
> to macrodef.
>
> 1) at the macrodef definition.
>
>
>
>
>
>
> dir @{dir}
>
Magesh Umasankar wrote:
From: Steve Loughran
Date: 2004-06-17 9:27:18
I am now convinced we need local properties; without
it macrodef doesnt work fully.
Why do you need them? I typically append an attribute
value to a property name to get the unique property that
I want.
I h
From: Steve Loughran
Date: 2004-06-17 9:27:18
> I am now convinced we need local properties; without
> it macrodef doesnt work fully.
Why do you need them? I typically append an attribute
value to a property name to get the unique property that
I want.
I have had reasonable succes
> From: Jack J. Woehr [mailto:[EMAIL PROTECTED]
>
> Jose Alberto Fernandez wrote:
>
> > The way I see it, a macrodef will also solve the issue of
> > concurrency. Notice that in all this cases the issue is how do you
> > refer to the value just generated. Lets assume you have the macro I
> >
Jose Alberto Fernandez wrote:
> The way I see it, a macrodef will also solve the issue
> of concurrency. Notice that in all this cases the issue is
> how do you refer to the value just generated. Lets assume you
> have the macro I defined before:
>
>
>
>
>
>
>
>
>
Of cour
> From: Jack J. Woehr [mailto:[EMAIL PROTECTED]
>
> It seems to me that if someone really needs this sort of
> thing, then the use of Ant-Contrib's Variable is pretty much
> sufficient, esp. if property parsing becomes recursive (e.g.,
> per the patch I submitted already) so that you can acces
Stefan Bodewig wrote:
> On Mon, 21 Jun 2004, Jose Alberto Fernandez
> <[EMAIL PROTECTED]> wrote:
> >> From: Stefan Bodewig [mailto:[EMAIL PROTECTED]
> >
> >> The main limitation I see without local properties in is
> >> when your macro uses a property setting task like or
> >> - you currently n
On Mon, 21 Jun 2004, Jose Alberto Fernandez
<[EMAIL PROTECTED]> wrote:
> True, but I doubt many people will use properties called for
> example:
>
> "#ant.task.macrodef.example.let1"
8-)
What if they do? Hypothetical, I know. Still we'd be carying them
around (and passing them down to s
> From: Stefan Bodewig [mailto:[EMAIL PROTECTED]
>
> > Because if that is the case, maybe we can solve the problem in a
> > completely different way, which is specific to .
>
> What you describe is pretty much what I (and probably anybody
> else) use as a workaround. I create what would be a
On Mon, 21 Jun 2004, Jose Alberto Fernandez
<[EMAIL PROTECTED]> wrote:
>> From: Stefan Bodewig [mailto:[EMAIL PROTECTED]
>
>> The main limitation I see without local properties in is
>> when your macro uses a property setting task like or
>> - you currently need to provide a unique property nam
I will go through what the patch does:
* whether we want to add a new block type that forces you to list the
scoped properties:
The patch does not have a new block type.
A new task - has been added.
defines a local property 'x' in the current "block" (target, sequential) which
is in the un-
> From: Stefan Bodewig [mailto:[EMAIL PROTECTED]
>
> On Mon, 21 Jun 2004, Jose Alberto Fernandez
> <[EMAIL PROTECTED]> wrote:
>
> > basically, I think we need to decide (by taking into account the
> > consequences) if this local properties ARE properties or
> are something
> > else that look
On Mon, 21 Jun 2004, Jose Alberto Fernandez
<[EMAIL PROTECTED]> wrote:
> basically, I think we need to decide (by taking into account the
> consequences) if this local properties ARE properties or are
> something else that look like properties.
Unless we want to change all property setting tasks,
> From: Stefan Bodewig [mailto:[EMAIL PROTECTED]
>
> Peter's original patch went beyond that, it introduced scoped
> properties on all the "block building" levels. Restricting
> "local" properties to the macrodef task and not allowing any
> other task to use the same mechanism feels wrong to
On Thu, 17 Jun 2004, Steve Loughran <[EMAIL PROTECTED]> wrote:
> I am now convinced we need local properties; without it macrodef
> doesnt work fully.
I could agree with "is less useful than it could be" 8-)
> One option: in the declaration, you declare which
> properties are local.
Peter's or
There is a patch in
http://issues.apache.org/bugzilla/show_bug.cgi?id=23942
It provides general purpose scoped local properties and it is thread safe.
Part of the discussion on the patch was:
http://marc.theaimsgroup.com/?l=ant-dev&m=106916954118249&w=2
Local properties may be declared in any "bloc
You can mostly kindof do this now by extending the PropertyHelper class and
installing an instance in the ant.PropertyHelper reference. I've done this
with two tasks and and both seem to work for most issues
with scoped property modifications (inside macros or not).
While you wait for Ant 1.6.3 o
I am still hoping we will have a multi-threaded ANT some time. Please
implement local properties in a thread-safe way. I think a separate
thread-local property store would be required for that.
- Alexey.
Steve Loughran wrote:
I am now convinced we need local properties; without it macrodef
does
I am now convinced we need local properties; without it macrodef doesnt
work fully.
One option: in the declaration, you declare which properties
are local. When the macro exits these properties are deleted -if they
were not set before entering the macro.
That is, properties set before the mac
On Thu, 27 Nov 2003, Peter reilly <[EMAIL PROTECTED]> wrote:
> Yesterday I said that macrodef attributes should be implemented as
> properties and not as textual substitution.
>
> On overnight reflection, I have changed by mind.
Cool, that makes two of us 8-)
> The proposed new notation is @{x}
essage-
> From: Peter reilly [mailto:[EMAIL PROTECTED]
> Sent: Thu 11/27/2003 7:08 AM
> To: [EMAIL PROTECTED]
> Cc:
> Subject: Macrodef attributes and Local revisited again
> Yesterday I said that macrodef attributes should be implemented as
> properties
t;
Or are you talking about properties defined within the execution of a "call" to
a macrodef?
-Original Message-
From: Peter reilly [mailto:[EMAIL PROTECTED]
Sent: Thu 11/27/2003 7:08 AM
To: [EMAIL PROTECTED]
Cc:
Subject: Macrodef attributes and Local revis
Yesterday I said that macrodef attributes should be implemented as
properties and not as textual substitution.
On overnight reflection, I have changed by mind.
MacroDef has been using textual substitution in the ant beta
builds without much problems (*.. well not quite see below).
The only issue
gzilla/show_bug.cgi?id=12951
Unable to use ejbc with ejb2.0 and local interfaces(getting out of memory
error with no stack trace)
[EMAIL PROTECTED] changed:
What|Removed |Added
45 matches
Mail list logo
