On Thu, 3 Jul 2008, Matt Benson <[EMAIL PROTECTED]> wrote:
> Surprising, actually, but given that this is the only
> noise I've seen on the thread I'd say that puts us in
> good shape to commit. :)
+1
Stefan
-
To unsubscribe,
On Thu, Jul 3, 2008 at 11:20 AM, Matt Benson <[EMAIL PROTECTED]> wrote:
> So, while I haven't even checked 1.6.3, 1.6.5, or
> 1.7.0 (the past is the past), it appears that both the
> impending release and the trunk outperform 1.6.2.
Excellent. Thanks for checking. +1. --DD
---
--- Dominique Devienne <[EMAIL PROTECTED]> wrote:
> On Wed, Jul 2, 2008 at 3:50 PM, Matt Benson
> <[EMAIL PROTECTED]> wrote:
> > I would be glad to run the diagnostics if given a
> > setup or at least your task-level performance
> analyzer.
>
> I've uploaded a jar as attachment to bug 23942 w/ m
On Wed, Jul 2, 2008 at 3:50 PM, Matt Benson <[EMAIL PROTECTED]> wrote:
> I would be glad to run the diagnostics if given a
> setup or at least your task-level performance analyzer.
I've uploaded a jar as attachment to bug 23942 w/ my timer listener. I
don't have a build setup to simulate high usa
--- Dominique Devienne <[EMAIL PROTECTED]> wrote:
> On Wed, Jul 2, 2008 at 2:31 PM, Matt Benson
> <[EMAIL PROTECTED]> wrote:
> > Dominique reminded me of
> > the performance problems that had been noted by
> Jan &
> > Steve; ...
> > http://markmail.org/message/ivjlvnqmygg4ap5f
>
> Actually it wa
On Wed, Jul 2, 2008 at 2:31 PM, Matt Benson <[EMAIL PROTECTED]> wrote:
> Dominique reminded me of
> the performance problems that had been noted by Jan &
> Steve; ...
> http://markmail.org/message/ivjlvnqmygg4ap5f
Actually it was http://markmail.org/message/rokgze4tfmwrwjab that I
had in mind, whi
On 8/28/07, Stefan Bodewig <[EMAIL PROTECTED]> wrote:
> On Mon, 27 Aug 2007, Peter Reilly <[EMAIL PROTECTED]> wrote:
> > On 8/27/07, Stefan Bodewig <[EMAIL PROTECTED]> wrote:
>
> >> How does nesting of locals work? If a macro calls another macro,
> >> are the properties set in the outer macro avai
On Mon, 27 Aug 2007, Peter Reilly <[EMAIL PROTECTED]> wrote:
> On 8/27/07, Stefan Bodewig <[EMAIL PROTECTED]> wrote:
>> How does nesting of locals work? If a macro calls another macro,
>> are the properties set in the outer macro available to the inner?
>> What about subbuilds invoked from insid
On 8/27/07, Stefan Bodewig <[EMAIL PROTECTED]> wrote:
> On Wed, 22 Aug 2007, Peter Reilly <[EMAIL PROTECTED]> wrote:
>
> > Hi all,
> > I have updated the local properties patch to
> > make use of the new PropertyHelper delegate infrastructure.
> > (see: http://issues.apache.org/bugzilla/show_bug.cg
On Wed, 22 Aug 2007, Peter Reilly <[EMAIL PROTECTED]> wrote:
> Hi all,
> I have updated the local properties patch to
> make use of the new PropertyHelper delegate infrastructure.
> (see: http://issues.apache.org/bugzilla/show_bug.cgi?id=23942)
Still haven't found the time to actually look at the
On 8/22/07, Matt Benson <[EMAIL PROTECTED]> wrote:
> Apologies for the top post but yours was rather long.
> ;) I like the approach patch; I have applied it but
> don't have time to exercise it ATM. The only issue I
> see is that I am apparently too stupid to understand
> how copying the current
Apologies for the top post but yours was rather long.
;) I like the approach patch; I have applied it but
don't have time to exercise it ATM. The only issue I
see is that I am apparently too stupid to understand
how copying the current stack for new threads works.
What I see:
kicks off a give
> From: Kev Jackson [mailto:[EMAIL PROTECTED]
>
>
>
>
>
>
> adding a scope parameter wouldn't be much use now, but for
> later on we
> could roll properties and local properties together with this
> strategy.
> Maybe people want to stick with properties because it's very
> well known
I can do that.
Is "define" a good name ?
Here's one vote for "my". Everyone in the programming
community would get that as a scoped entity immediately.
I know that we already have global properties and that this is looking
at local properties, but could we no tlook further forward (toward
Peter Reilly wrote:
>
> Jose Alberto Fernandez wrote:
> >
> I can do that.
> Is "define" a good name ?
Here's one vote for "my". Everyone in the programming
community would get that as a scoped entity immediately.
--
Jack J. Woehr # The year 2005 marks the
PO Box 51, Golden, CO
Will it work, if I want to load a file into some "temporary local entity"?
- Alexey.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Alexey N. Solofnenko wrote:
It does not say "local" anywhere. Should it be ?
The "define" element does not create a local property, all it does
is generate a value for an attribute. This value can be used for any
purpose that the macro author may think of. The value is constructed
so that a differe
prefer plain because it is simple.
Jose Alberto
> -Original Message-
> From: Alexey N. Solofnenko [mailto:[EMAIL PROTECTED]
> Sent: 12 January 2005 18:30
> To: Ant Developers List
> Subject: Re: local properties
>
>
> It does not say "local" anyw
It does not say "local" anywhere. Should it be ?
- Alexey.
Peter Reilly wrote:
I can do that.
Is "define" a good name ?
Peter
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
since I do not have it
at hand from work.
Let me know it you prefer me to apply it.
Cheers,
Jose Alberto
-Original Message-
From: Peter Reilly [mailto:[EMAIL PROTECTED]
Sent: 11 January 2005 15:41
To: Ant Developers List
Subject: Re: local properties
Jose Alberto Fernandez wrote:
o apply it.
Cheers,
Jose Alberto
> -Original Message-
> From: Peter Reilly [mailto:[EMAIL PROTECTED]
> Sent: 11 January 2005 15:41
> To: Ant Developers List
> Subject: Re: local properties
>
>
> Jose Alberto Fernandez wrote:
>
> >&
Peter Reilly wrote:
Jose Alberto Fernandez wrote:
From: Peter Reilly [mailto:[EMAIL PROTECTED]
Wouldn't mind having the two, and see what works best. :-)
Sounds good, but is it possible to get a different name than "let" ?
Hey, just propose a name for it. I am flexible... :-)
Stefan
Jose Alberto Fernandez wrote:
From: Peter Reilly [mailto:[EMAIL PROTECTED]
Wouldn't mind having the two, and see what works best. :-)
Sounds good, but is it possible to get a different name than "let" ?
Hey, just propose a name for it. I am flexible... :-)
Stefan's suggestion
> From: Peter Reilly [mailto:[EMAIL PROTECTED]
>
> >
> >Wouldn't mind having the two, and see what works best. :-)
> >
> >
> Sounds good, but is it possible to get a different name than "let" ?
>
Hey, just propose a name for it. I am flexible... :-)
Jose Alberto
On Tue, 11 Jan 2005, Kev Jackson <[EMAIL PROTECTED]> wrote:
>
>> Sounds good, but is it possible to get a different name than "let"
>> ?
>>
>> Peter
>
> Following the VBness of "let", how about "dim"? ;)
Actually it's a Lispness - for those of us who liked the name let, at
least 8-)
Hmm, borrow
Or use perl's "local" or even "my" (the latter suggestion being a joke -
which is likely to back-fire as usual). ;n)
Phil :n)
On Tue, 2005-01-11 at 11:52, Kev Jackson wrote:
> > Sounds good, but is it possible to get a different name than "let" ?
> >
> > Peter
>
> Following the VBness of "let",
Sounds good, but is it possible to get a different name than "let" ?
Peter
Following the VBness of "let", how about "dim"? ;)
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Jose Alberto Fernandez wrote:
From: Peter Reilly [mailto:[EMAIL PROTECTED]
Jose Alberto Fernandez wrote:
As per other approaches to local properties, unless we go
and define a
real semantic for them (like any other well design
programming language
out there) I see
> From: Peter Reilly [mailto:[EMAIL PROTECTED]
>
> Jose Alberto Fernandez wrote:
>
> >As per other approaches to local properties, unless we go
> and define a
> >real semantic for them (like any other well design
> programming language
> >out there) I see they creating more problems than sol
--- Peter Reilly <[EMAIL PROTECTED]> wrote:
[SNIP]
> As the main use case for local properties is
> we
> could just implement them for macrodefs, and if
> necessary
> extend them later to be the free style properties.
[SNIP]
> We could implement this as a trial in ant cvs and
> pull it if there a
Antoine Levy-Lambert wrote:
> what is the number of your bug report ?
http://issues.apache.org/bugzilla/show_bug.cgi?id=29347
--
Jack J. Woehr # The year 2005 marks the
PO Box 51, Golden, CO 80402 # thirtieth anniversary of my
http://www.well.com/~jax # entry into anti-WO
Hi,
my 2 cents,
I like rather than (the latter reminds me of
Visual Basic, oh shame).
I also like it if the local property is thread safe, because this might
be useful for some advanced ant users.
Peter, I would like it if you try it in cvs.
Cheers,
Antoine
Peter Reilly wrote:
Jose Alberto Fe
Hello Jack,
what is the number of your bug report ?
Cheers,
Antoine
Jack J. Woehr wrote
And recursive property expansion! @[EMAIL PROTECTED]@{property}.expansion}!
I believe an implementation of this still languishes as a code example
in a bug I filed ...
---
Peter Reilly wrote:
>
> Jose Alberto Fernandez wrote:
>
> >We left it nowhere.
> >
> >
> Is true.
>
> >
> >I still think my simple addition to will solve 90% of the
> >use cases
> >with very low impact across the code. But as anything, people will have to
> >understand
> >when to use it prop
Jose Alberto Fernandez wrote:
We left it nowhere.
Is true.
I still think my simple addition to will solve 90% of
the use cases
with very low impact across the code. But as anything, people will have to
understand
when to use it properly and so on.
The patch is there in bugzilla, but I will n
We left it nowhere.
I still think my simple addition to will solve 90% of the
use cases
with very low impact across the code. But as anything, people will have to
understand
when to use it properly and so on.
The patch is there in bugzilla, but I will not apply it unless there is some
supp
--- Jose Alberto Fernandez <[EMAIL PROTECTED]>
wrote:
> I would like to hear comments about having an
> "antlib" scope. I.e.,
> global but visible only to tasks defined in the same
> antlib. This
> will give you a concept similar to "module
> variables" in many
> programming languages.
That is a
[EDITED]
--- Stefan Bodewig <[EMAIL PROTECTED]> wrote:
> On Wed, 20 Oct 2004, Matt Benson
> <[EMAIL PROTECTED]> wrote:
> > So that instead of declaring which properties do
> NOT
> > remain, we declare which properties DO remain.
>
> What would be the gain? How would this simplify
> things?
>
> L
> From: Stefan Bodewig [mailto:[EMAIL PROTECTED]
>
> On Thu, 21 Oct 2004, Jose Alberto Fernandez
> <[EMAIL PROTECTED]> wrote:
>
> > How about structuring this local variables scope as follows:
> >
> >
> >
> >
> >
> >
>
> I don't see any use for the super scope myself,
On Thu, 21 Oct 2004, Jose Alberto Fernandez
<[EMAIL PROTECTED]> wrote:
> How about structuring this local variables scope as follows:
>
>
>
>
>
>
I don't see any use for the super scope myself, but if it helps to
reach consensus ...
> And it cover all the cases of prefi
[... skipping the name discussion since I'm responsible for many
misnomers in Ant already 8-) ...]
On Wed, 20 Oct 2004, Matt Benson <[EMAIL PROTECTED]> wrote:
> So that instead of declaring which properties do NOT
> remain, we declare which properties DO remain.
What would be the gain? How woul
Not that I am giving up on my proposal or anything :-)
But since I think they both can coexist as tools for people to use as
they please,
How about structuring this local variables scope as follows:
${1} ${2} ${3}
${1} ${2} ${3}
${1} ${2}
Jose Alberto Fernandez wrote:
Do we copy, not copy, almost copy? What happens if I declare
a parallel with a ? inside a macrodef.
The stack of "pointers" (pointers being the java variable as seen by a C
programmer) is copied.
The following works fine:
> From: Peter Reilly [mailto:[EMAIL PROTECTED]
>
> Jose Alberto Fernandez wrote:
>
> >>From: Peter Reilly [mailto:[EMAIL PROTECTED]
> >>
> >> From the point of view of most languages, there is a flat
> >>namespace. For example in "C" one can do
> >>
> >>int a;
> >>
> >>void proc(void) {
> >> i
> From: Dominique Devienne [mailto:[EMAIL PROTECTED]
>
> > From: Jose Alberto Fernandez [mailto:[EMAIL PROTECTED]
> > > From: Dominique Devienne [mailto:[EMAIL PROTECTED]
> > > > From: Stefan Bodewig [mailto:[EMAIL PROTECTED]
> > > 1) I don't like the name. Perhaps it shows how ignorant I am
> >
> From: Jose Alberto Fernandez [mailto:[EMAIL PROTECTED]
> > From: Dominique Devienne [mailto:[EMAIL PROTECTED]
> > > From: Stefan Bodewig [mailto:[EMAIL PROTECTED]
> > 1) I don't like the name. Perhaps it shows how ignorant I am
> >about other languages not in the C family, but it doesn't spe
Jose Alberto Fernandez wrote:
From: Peter Reilly [mailto:[EMAIL PROTECTED]
From the point of view of most languages, there is a flat
namespace. For example in "C" one can do
int a;
void proc(void) {
int a;
a = 1;
}
Peter
Sorry, but you are mistaken here. The "a" being assigned is diffe
> From: Peter Reilly [mailto:[EMAIL PROTECTED]
>
> From the point of view of most languages, there is a flat
> namespace. For example in "C" one can do
>
> int a;
>
> void proc(void) {
>int a;
>a = 1;
> }
>
> Peter
>
Sorry, but you are mistaken here. The "a" being assigned is diffe
> From: Dominique Devienne [mailto:[EMAIL PROTECTED]
>
> > From: Stefan Bodewig [mailto:[EMAIL PROTECTED]
> >
> > To me is the correct solution that may need to get
> extended to
> > cover additional cases. Your task that generates unique names has
> > merits of its own and independent of t
Jose Alberto Fernandez wrote:
Peter,
The original reason for all the threadlocal stuff was to allow writing
things like:
Where "macro1" defines locals and in that case we do not want the
different threads to interfere with each other. Now does your changes
deal with this issue
> From: Peter Reilly [mailto:[EMAIL PROTECTED]
>
> Stefan Bodewig wrote:
>
> >Nicer? Maybe. I still think a special task container would
> be cleaner
> >since it provided explicit scoping and might even help us
> route around
> >the "custom PropertyHelpers problem". Something like
> >
> >
> From: Stefan Bodewig [mailto:[EMAIL PROTECTED]
>
> To me is the correct solution that may need to get extended to
> cover additional cases. Your task that generates unique names has
> merits of its own and independent of that. Your (much simpler)
> approach would need an additional cleanup mo
--- Stefan Bodewig <[EMAIL PROTECTED]> wrote:
> This is what you get when you say "do as you please,
> I don't have time
> to fight for my solution"? I should try it more
> often ;-)
I originally thought about a "scope" Sequential
subclass as well. In fact, when I got into my email
today I plann
Stefan Bodewig wrote:
On Wed, 20 Oct 2004, Peter Reilly <[EMAIL PROTECTED]> wrote:
Ok, I am modifying the local patch to do:
prop is ${prop}
This is what you get when you say "do as you please, I don't have time
to fight for my solution"? I should try it more often ;-)
Well
On Tue, 19 Oct 2004, Jose Alberto Fernandez
<[EMAIL PROTECTED]> wrote:
> BTW, a long time ago I went on proposing something like this, to
> have a real stack of property definitions, shadowing, and so on. But
> there are a lot of funny issues that made it very dificult and a lot
> of compatibility
On Wed, 20 Oct 2004, Peter Reilly <[EMAIL PROTECTED]> wrote:
> Ok, I am modifying the local patch to do:
>
>
>
>
> prop is ${prop}
>
>
This is what you get when you say "do as you please, I don't have time
to fight for my solution"? I should try it more often ;-)
Stefan
-
Stefan Bodewig wrote:
Nicer? Maybe. I still think a special task container would be
cleaner since it provided explicit scoping and might even help us
route around the "custom PropertyHelpers problem". Something like
prop is ${prop}
Ok, I am modifying the local patch to do:
Jack J. Woehr wrote:
Stefan Bodewig wrote:
Nor the other way around. You've convinced me, we need shadowing.
Shadowing, or a definition stack for each definition?
That is the way the local patch works.
But it is not as clean as it should be, in that user properties and normal
properties
Jose Alberto Fernandez wrote:
For example, the usage of ThreadLocals in other
proposals may be right for some things, but it may be wrong if I am
trying to use properties to communicate between threads. (Which I can do
with regular properties).
You are correct.
Using the following:
> From: Stefan Bodewig [mailto:[EMAIL PROTECTED]
>
> On Fri, 15 Oct 2004, Jose Alberto Fernandez
> <[EMAIL PROTECTED]> wrote:
>
> > I just want to say that in my proposal, the temporary
> properties only
> > last for as long as the Project instance is executing.
>
> I know, still that might
Stefan Bodewig wrote:
> Nor the other way around. You've convinced me, we need shadowing.
Shadowing, or a definition stack for each definition? That's the way m4 works
[ pushdef() ] and I've implemented that in object Forth.
--
Jack J. Woehr # Libertarian candidate
PO Box 51, Go
On Fri, 15 Oct 2004, Peter Reilly <[EMAIL PROTECTED]> wrote:
> Since we are really only worried about the macrodef usecase, we
> could initially just deal with this using the syntax:
>
>
>
>
>
>
>
>
>
>
>
> I.e have a local nested element for - this
On Fri, 15 Oct 2004, Jose Alberto Fernandez
<[EMAIL PROTECTED]> wrote:
> I just want to say that in my proposal, the temporary properties
> only last for as long as the Project instance is executing.
I know, still that might be too much. GridAnt is one such case, and I
think there's been some ki
I hate when I reply to my own messages, but I think
some additional remarks are granted here.
> From: Jose Alberto Fernandez
>
> > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> >
> >
> > > >Havent got an answer to that proposal:
> > > >
> > > >
> > >
> > > I do not see how it wo
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
>
>
> > >Havent got an answer to that proposal:
> > >
> > >
> >
> > I do not see how it would be useful
>
> You could use all other tasks as they are. Many tasks store
> their result in properties. Some (like loadproperties) in
> mu
Jose Alberto Fernandez wrote:
Notice, that except for the access to the HashMap containing the
properties
you do not need to do much more in the sense of thread safety.
The names are unique, hence there is no two threads with the same
property
(unless the name gets passed from a common parent) but
> From: Steve Loughran [mailto:[EMAIL PROTECTED]
>
>
> On Thu, 14 Oct 2004 11:26:56 +0200, Stefan Bodewig
> <[EMAIL PROTECTED]>
> wrote:
> > Hmm, ask Steve how long a SmartFrog instance is running.
> And AFAIU > NetBeans 4 runs a single instance of Ant as long
> as the IDE is > running.
On Thu, 14 Oct 2004 11:26:56 +0200, Stefan Bodewig <[EMAIL PROTECTED]>
wrote:
> Hmm, ask Steve how long a SmartFrog instance is running. And AFAIU
> NetBeans 4 runs a single instance of Ant as long as the IDE is
> running. This may really lead to quite a few properties at the end of
> the day, i
> From: Peter Reilly [mailto:[EMAIL PROTECTED]
>
> Stefan Bodewig wrote:
>
> >Trying to consolidate a few answers since I'm very late to the party
> >anyway.
> >
> >On Fri, 08 Oct 2004, Peter Reilly <[EMAIL PROTECTED]> wrote:
> >
> >
> >>>2) All these uniquely named properties go on living afte
On Thu, 14 Oct 2004 11:26:56 +0200, Stefan Bodewig <[EMAIL PROTECTED]>
wrote:
> Hmm, ask Steve how long a SmartFrog instance is running. And AFAIU
> NetBeans 4 runs a single instance of Ant as long as the IDE is
> running. This may really lead to quite a few properties at the end of
> the day, i
> From: Stefan Bodewig [mailto:[EMAIL PROTECTED]
>
> Trying to consolidate a few answers since I'm very late to
> the party anyway.
>
> On Fri, 08 Oct 2004, Peter Reilly <[EMAIL PROTECTED]> wrote:
>
> > I have had a proposal outstanding for a while for local properties:
>
> a long while.
>
>
Stefan Bodewig wrote:
Trying to consolidate a few answers since I'm very late to the party
anyway.
On Fri, 08 Oct 2004, Peter Reilly <[EMAIL PROTECTED]> wrote:
I have had a proposal outstanding for a while for local properties:
a long while.
My preferences haven't changed much over time, but I'm f
OK, separate answer since this really belongs on a separate thread.
On Fri, 08 Oct 2004, Wascally Wabbit <[EMAIL PROTECTED]>
wrote:
> o Should PropertyHelper replacements honor currently attached
>hooks?
I'm really sorry to admit that I'm not familiar enough with the code
to comment on it.
Trying to consolidate a few answers since I'm very late to the party
anyway.
On Fri, 08 Oct 2004, Peter Reilly <[EMAIL PROTECTED]> wrote:
> I have had a proposal outstanding for a while for local properties:
a long while.
My preferences haven't changed much over time, but I'm far too busy to
he
> From: Matt Benson [mailto:[EMAIL PROTECTED]
>
> I have yet to see a good argument why people should be
> uncomfortable with the notion that their bodies are host to
> millions of microscopic parasites, but that doesn't mean I
> have to be wild about the idea. So there's my reason--I just
>
> From: Alexey N. Solofnenko [mailto:[EMAIL PROTECTED]
>
> I would rather put into a build file, because it is a property of a
> build file to use this feature.
Yes Alexey, I agree with you. I've long thought that it's really
strange there are a lot of things you cannot easily do from within
the
Dominique Devienne wrote:
> > While we're on the subject, anyone still thinking about recursive
> > property expansion?
>
> Yes, Peter just mentioned it. And I also support it, FWIW.
> I'd prefer to have it built-in to core too, possibly with a
> command line switch to explicitly enable it to be
I would rather put into a build file, because it is a property of a
build file to use this feature.
- Alexey.
Dominique Devienne wrote:
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Jose Alberto Fernandez wrote:
It is a very small addition to macro and it does not require
any changes to
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
>
> Jose Alberto Fernandez wrote:
>
> > It is a very small addition to macro and it does not require
> > any changes to the ANT machinery. I think everything we want
> > to be able to do in macros can be done this way.
>
> While we're on the su
Jose Alberto Fernandez wrote:
> It is a very small addition to macro and it does not require
> any changes to the ANT machinery. I think everything we want
> to be able to do in macros can be done this way.
While we're on the subject, anyone still thinking about recursive
property expansion?
--
--- Jose Alberto Fernandez <[EMAIL PROTECTED]>
wrote:
[SNIP]
> > From: Dominique Devienne
[SNIP]
> > 2) All these uniquely named properties go on
> living after
> >the macro has executed. That pollutes the
> namespace.
> >
>
> Yes it does. But I still have to see a good argument
> on why shal
--- Steve Loughran <[EMAIL PROTECTED]> wrote:
[SNIP]
> Regarding nesting of property resolution, which is
> also on that thread
> ${${b}.c} this reminds me too much of pointers. If
> we want something
> like that, lets have a hashtable-like syntax
>
> ${myprops[${b}]}
>
I have nothing against r
1. I like the implementation simplicity of Jose's solution. We chould
check it in now and see how well it works in practice, with the warnign
we can pull it right up to the moment Ant1.7.0 ships.
2. I also like the conceptual model of for anyone experienced in
using local variables. It does in
1) It's like polluting a tranditional program's variable space
with stuff the application did not explicitly cause -- it makes
debugging more difficult (and confusing if the results of the
Ant execution is published in a readonly format like a website).
2) The previous state
Ok, here are my responses:
> From: Dominique Devienne [mailto:[EMAIL PROTECTED]
>
>
> I haven't looked at your impl Peter, but there are two things
> about Jose Alberto's proposal I wanted to note:
>
> 1) The generated unique name would need to at least use the
>'let' name's as a prefix,
I think that the current way of doing propery helpers and hooks
is a bit wrong:
1) one can both replace the property helper (by setting a reference),
and one can put hooks in. Both are difficult to use and have bugs.
2) I would like to have recursive property resolution (even if it causes
Let me get to your comments first :-)
> From: Peter Reilly [mailto:[EMAIL PROTECTED]
>
> Yes I have seen it.
> I do not like it, - the [EMAIL PROTECTED] syntax is a bit ikky ;-)
> However, it does solve the macrodef use case so if people
> go for it, I would have no objection.!
>
The synta
QUESTIONS ON PropertyHelper (Ant 1.6+) ANT-dev mailing list:
o Should PropertyHelper replacements honor currently attached
hooks? What if a hook is attached and then the helper is
unset (reset to the original Ant-installed one?) Should the
(new) hooks be "moved" to the original helper?
o Can
> From: Peter Reilly [mailto:[EMAIL PROTECTED]
> Jose Alberto Fernandez wrote:
>
> >I just posted something on bug 23942 about a different approach
> >to this issue that I implemented on my machine at home.
> >
> >It is a very small addition to macro and it does not require
> >any changes to the A
Jose Alberto Fernandez wrote:
Peter,
I just posted something on bug 23942 about a different approach
to this issue that I implemented on my machine at home.
It is a very small addition to macro and it does not require
any changes to the ANT machinery. I think everything we want
to be able to do in
Peter,
I just posted something on bug 23942 about a different approach
to this issue that I implemented on my machine at home.
It is a very small addition to macro and it does not require
any changes to the ANT machinery. I think everything we want
to be able to do in macros can be done this way.
91 matches
Mail list logo
