AW: Ant 1.6 local and macrodef attributes
Hi Peter,
I have been quite silent recently because I am busy at work ...
I am OK for the @{attributename} syntax for the textual substitution of
attributes in macrodef.
Cheers,
Antoine
-Ursprüngliche Nachricht-
Von: Peter Reilly [mailto:[EMAIL PROTECTED]
Gesendet: Montag, 1. Dezember 2003 09:59
An: Ant Developers List
Cc: Steve Cohen; [EMAIL PROTECTED]
Betreff: Re: Ant 1.6 local and macrodef attributes
The work-around [EMAIL PROTECTED] will work.
prop.name is @{prop.name} prop value is
'[EMAIL PROTECTED]'
results in:
[echo] prop.name is prop prop value is 'This is the value of prop'
The @{} update has not been applied yet - still waiting for positive
feedback from ant committers.
Peter
Jacob Kjome wrote:
>
> Thanks for that Steve. I really appreciate you going the extra mile
> to help out with a solution to this predicament. If your example
> below actually works with Ant-1.6 final then, ugly or not, I'll be
> satisfied with the temporary solution and will patiently wait for a
> less hacky solution in Ant-1.7.
>
> Can anyone verify that Steve's work around actually works? When will
> the @{x} stuff be committed to the 1.6 branch (or is it already)? I'd
> like to test it out ASAP.
>
> Jake
>
> At 10:20 AM 11/29/2003 -0600, Steve Cohen wrote:
>
>>
>>
>> Thanks, Jacob, for continuing to pursue this, and deepening my
>> awareness of the problem.
>>
>> I appreciate your dilemma, even though I still agree with what has
>> become consensus that textual substitution is right for .
>> The whole business with the scope of properties is already
>> complicated enough. The patch or something like it will be
>> necessary to solve your use case. But is the right thing?
>> Maybe we need to think more generally (not, heaven forbid, for
>> 1.6!!!) about tasks that return values in properties and how these
>> should be implemented in the context of macrodefs.
>>
>> The key point is that when such a property was called inside of an
>> antcall that created a property locally within the execution context
>> of the call. Textual substitution destroys that. A
>> looks like a separate execution context but is not, at
>> least not as currently set up.
>>
>> Since that is unlikely to be resolved in time for 1.6, can we suggest
>> a workaround for the interim?
>>
>> I think we can. It's a bit ugly, but it does allow us to replace
>> macrodefs calling tasks that return properties, even without
>> . We just add one level of indirection.
>>
>> Instead of this:
>>
>>
>>
>>
>> > file="@{test.file}"/>
>>
>> Is @{test.file} available? ${file.available}.
>>
>>
>> ...
>>
>> ...
>>
>>
>> where the problem is that the property "file.available" cannot be
>> redefined a second time now because the macrodef lives outside of any
>> target and this property therefore resides on top level
>>
>> we can instead do this:
>>
>>
>>
>>
>>
>> > value = "yes"
>> file="@{test.file}"/>
>>
>> Is @{test.file} available? [EMAIL PROTECTED]
>>
>>
>> ...
>>
>> ...
>>
>>
>> This is annoyingly less simple than but still allows
>> to be used in 1.6 with tasks that return values in
>> properties. I am assuming that
>> [EMAIL PROTECTED] would be handled correctly by textual
>> expansion. Someone please correct me if I'm wrong.
>>
>>
>>
>>
>> -Original Message-
>> From: Jacob Kjome [<mailto:[EMAIL PROTECTED]>mailto:[EMAIL PROTECTED]
>> Sent: Fri 11/28/2003 6:39 PM
>> To: Ant Users List
>> Cc:
>> Subject:RE: Ant 1.6 local and macrodef attributes
>>
>> Thanks for explaining that Peter.
>>
>> I took a look and found your latest proposal here...
>>
<http://marc.theaimsgroup.com/?l=ant-dev&m=106993855725136&w=2>http://marc.t
heaimsgroup.com/?l=ant-dev&m=106993855725136&w=2
>>
>>
>> Seems that Stefan liked it...
>>
<http://marc.theaimsgroup.com/?l=ant-dev&m=106994393230831&w=2>http://marc.t
heaimsgroup.com/?l=ant-dev&m=106994393230831&w=2
>>
>>
>> So, I guess that means that proposal #1 below is going to be implemented
>> for Ant-1.6. However, does this still leave properties out to
>> dry? I'm totally fine with usin
Re: Ant 1.6 local and macrodef attributes
The work-around [EMAIL PROTECTED] will work.
prop.name is @{prop.name} prop value is
'[EMAIL PROTECTED]'
results in:
[echo] prop.name is prop prop value is 'This is the value of prop'
The @{} update has not been applied yet - still waiting for positive
feedback from ant committers.
Peter
Jacob Kjome wrote:
Thanks for that Steve. I really appreciate you going the extra mile
to help out with a solution to this predicament. If your example
below actually works with Ant-1.6 final then, ugly or not, I'll be
satisfied with the temporary solution and will patiently wait for a
less hacky solution in Ant-1.7.
Can anyone verify that Steve's work around actually works? When will
the @{x} stuff be committed to the 1.6 branch (or is it already)? I'd
like to test it out ASAP.
Jake
At 10:20 AM 11/29/2003 -0600, Steve Cohen wrote:
Thanks, Jacob, for continuing to pursue this, and deepening my
awareness of the problem.
I appreciate your dilemma, even though I still agree with what has
become consensus that textual substitution is right for .
The whole business with the scope of properties is already
complicated enough. The patch or something like it will be
necessary to solve your use case. But is the right thing?
Maybe we need to think more generally (not, heaven forbid, for
1.6!!!) about tasks that return values in properties and how these
should be implemented in the context of macrodefs.
The key point is that when such a property was called inside of an
antcall that created a property locally within the execution context
of the call. Textual substitution destroys that. A
looks like a separate execution context but is not, at
least not as currently set up.
Since that is unlikely to be resolved in time for 1.6, can we suggest
a workaround for the interim?
I think we can. It's a bit ugly, but it does allow us to replace
macrodefs calling tasks that return properties, even without
. We just add one level of indirection.
Instead of this:
Is @{test.file} available? ${file.available}.
...
...
where the problem is that the property "file.available" cannot be
redefined a second time now because the macrodef lives outside of any
target and this property therefore resides on top level
we can instead do this:
Is @{test.file} available? [EMAIL PROTECTED]
...
...
This is annoyingly less simple than but still allows
to be used in 1.6 with tasks that return values in
properties. I am assuming that
[EMAIL PROTECTED] would be handled correctly by textual
expansion. Someone please correct me if I'm wrong.
-Original Message-
From: Jacob Kjome [<mailto:[EMAIL PROTECTED]>mailto:[EMAIL PROTECTED]
Sent: Fri 11/28/2003 6:39 PM
To: Ant Users List
Cc:
Subject:RE: Ant 1.6 local and macrodef attributes
Thanks for explaining that Peter.
I took a look and found your latest proposal here...
<http://marc.theaimsgroup.com/?l=ant-dev&m=106993855725136&w=2>http://marc.theaimsgroup.com/?l=ant-dev&m=106993855725136&w=2
Seems that Stefan liked it...
<http://marc.theaimsgroup.com/?l=ant-dev&m=106994393230831&w=2>http://marc.theaimsgroup.com/?l=ant-dev&m=106994393230831&w=2
So, I guess that means that proposal #1 below is going to be implemented
for Ant-1.6. However, does this still leave properties out to
dry? I'm totally fine with using @{x} syntax for attributes, but
macrodef
is still mostly useless to me unless I can do...
Is @{test.file} available? ${file.available}.
Jake
At 06:33 PM 11/27/2003 +, you wrote:
>Hi Jacob,
>Most of this discussion is on the dev listing.
>I can understand your confusion.
>
>A brief history.
>(You can search with keyword local at
><http://marc.theaimsgroup.com/?l=ant-dev&r=1&w=2>http://marc.theaimsgroup
.com/?l=ant-dev&r=1&w=2
>to get the full gory details)
>
>When macrodef was written originally, attributes
>were (and are) implemented as textual substitution.
>This was ok but they looked like normal properties
>(using the ${x} notation). This caused a lot of
>debate/confusion but I resisted changing the notation as I
>do not like using different notation.
>
>After using macrodefs for a little while I and other
>people became aware that ant uses properties for
>passing information between tasks and only having
>non-mutable properties reduce the usefulness of
>macrodefs a lot.
>
>One can use ant-contrib's propertyregex and (via antelope)
>var, and just overwrite properties - but this felt
>like a big hack.
>
>So one week-end I said what the heck and attempted to
>implement local properties. It when through a number
>of iteration
RE: Ant 1.6 local and macrodef attributes
Thanks for that Steve. I really appreciate you going the extra mile to
help out with a solution to this predicament. If your example below
actually works with Ant-1.6 final then, ugly or not, I'll be satisfied with
the temporary solution and will patiently wait for a less hacky solution in
Ant-1.7.
Can anyone verify that Steve's work around actually works? When will the
@{x} stuff be committed to the 1.6 branch (or is it already)? I'd like to
test it out ASAP.
Jake
At 10:20 AM 11/29/2003 -0600, Steve Cohen wrote:
Thanks, Jacob, for continuing to pursue this, and deepening my awareness
of the problem.
I appreciate your dilemma, even though I still agree with what has become
consensus that textual substitution is right for . The whole
business with the scope of properties is already complicated enough. The
patch or something like it will be necessary to solve your use
case. But is the right thing? Maybe we need to think more
generally (not, heaven forbid, for 1.6!!!) about tasks that return values
in properties and how these should be implemented in the context of macrodefs.
The key point is that when such a property was called inside of an antcall
that created a property locally within the execution context of the
call. Textual substitution destroys that. A looks
like a separate execution context but is not, at least not as currently set up.
Since that is unlikely to be resolved in time for 1.6, can we suggest a
workaround for the interim?
I think we can. It's a bit ugly, but it does allow us to replace
macrodefs calling tasks that return properties, even without . We
just add one level of indirection.
Instead of this:
Is @{test.file} available? ${file.available}.
...
...
where the problem is that the property "file.available" cannot be
redefined a second time now because the macrodef lives outside of any
target and this property therefore resides on top level
we can instead do this:
Is @{test.file} available? [EMAIL PROTECTED]
...
...
This is annoyingly less simple than but still allows to
be used in 1.6 with tasks that return values in properties. I am assuming that
[EMAIL PROTECTED] would be handled correctly by textual
expansion. Someone please correct me if I'm wrong.
-Original Message-
From: Jacob Kjome [<mailto:[EMAIL PROTECTED]>mailto:[EMAIL PROTECTED]
Sent: Fri 11/28/2003 6:39 PM
To: Ant Users List
Cc:
Subject:RE: Ant 1.6 local and macrodef attributes
Thanks for explaining that Peter.
I took a look and found your latest proposal here...
<http://marc.theaimsgroup.com/?l=ant-dev&m=106993855725136&w=2>http://marc.theaimsgroup.com/?l=ant-dev&m=106993855725136&w=2
Seems that Stefan liked it...
<http://marc.theaimsgroup.com/?l=ant-dev&m=106994393230831&w=2>http://marc.theaimsgroup.com/?l=ant-dev&m=106994393230831&w=2
So, I guess that means that proposal #1 below is going to be implemented
for Ant-1.6. However, does this still leave properties out to
dry? I'm totally fine with using @{x} syntax for attributes, but macrodef
is still mostly useless to me unless I can do...
Is @{test.file} available? ${file.available}.
Jake
At 06:33 PM 11/27/2003 +, you wrote:
>Hi Jacob,
>Most of this discussion is on the dev listing.
>I can understand your confusion.
>
>A brief history.
>(You can search with keyword local at
><http://marc.theaimsgroup.com/?l=ant-dev&r=1&w=2>http://marc.theaimsgroup
.com/?l=ant-dev&r=1&w=2
>to get the full gory details)
>
>When macrodef was written originally, attributes
>were (and are) implemented as textual substitution.
>This was ok but they looked like normal properties
>(using the ${x} notation). This caused a lot of
>debate/confusion but I resisted changing the notation as I
>do not like using different notation.
>
>After using macrodefs for a little while I and other
>people became aware that ant uses properties for
>passing information between tasks and only having
>non-mutable properties reduce the usefulness of
>macrodefs a lot.
>
>One can use ant-contrib's propertyregex and (via antelope)
>var, and just overwrite properties - but this felt
>like a big hack.
>
>So one week-end I said what the heck and attempted to
>implement local properties. It when through a number
>of iterations.
>
>When this was done, I realized that attributes could
>be implemented by local properties and the problems
>with notation would go away.
>
>This interpretation of reality was not (to say the
>least) universally accepted.
>
>After the 1000'th e-mail explaining what was wrong
>with this, I realized that there may be a point
>in the argument
RE: Ant 1.6 local and macrodef attributes
Thanks, Jacob, for continuing to pursue this, and deepening my awareness of the
problem.
I appreciate your dilemma, even though I still agree with what has become
consensus that textual substitution is right for . The whole
business with the scope of properties is already complicated enough. The
patch or something like it will be necessary to solve your use case.
But is the right thing? Maybe we need to think more generally (not,
heaven forbid, for 1.6!!!) about tasks that return values in properties and how
these should be implemented in the context of macrodefs.
The key point is that when such a property was called inside of an antcall that
created a property locally within the execution context of the call.
Textual substitution destroys that. A looks like a separate
execution context but is not, at least not as currently set up.
Since that is unlikely to be resolved in time for 1.6, can we suggest a
workaround for the interim?
I think we can. It's a bit ugly, but it does allow us to replace macrodefs
calling tasks that return properties, even without . We just add one
level of indirection.
Instead of this:
Is @{test.file} available? ${file.available}.
...
...
where the problem is that the property "file.available" cannot be redefined a
second time now because the macrodef lives outside of any target and this
property therefore resides on top level
we can instead do this:
Is @{test.file} available? [EMAIL PROTECTED]
...
...
This is annoyingly less simple than but still allows to be
used in 1.6 with tasks that return values in properties. I am assuming that
[EMAIL PROTECTED] would be handled correctly by textual expansion. Someone
please correct me if I'm wrong.
-Original Message-
From: Jacob Kjome [mailto:[EMAIL PROTECTED]
Sent: Fri 11/28/2003 6:39 PM
To: Ant Users List
Cc:
Subject: RE: Ant 1.6 local and macrodef attributes
Thanks for explaining that Peter.
I took a look and found your latest proposal here...
http://marc.theaimsgroup.com/?l=ant-dev&m=106993855725136&w=2
Seems that Stefan liked it...
http://marc.theaimsgroup.com/?l=ant-dev&m=106994393230831&w=2
So, I guess that means that proposal #1 below is going to be implemented
for Ant-1.6. However, does this still leave properties out to
dry? I'm totally fine with using @{x} syntax for attributes, but macrodef
is still mostly useless to me unless I can do...
Is @{test.file} available? ${file.available}.
Jake
At 06:33 PM 11/27/2003 +, you wrote:
>Hi Jacob,
>Most of this discussion is on the dev listing.
>I can understand your confusion.
>
>A brief history.
>(You can search with keyword local at
>http://marc.theaimsgroup.com/?l=ant-dev&r=1&w=2
>to get the full gory details)
>
>When macrodef was written originally, attributes
>were (and are) implemented as textual substitution.
>This was ok but they looked like normal properties
>(using the ${x} notation). This caused a lot of
>debate/confusion but I resisted changing the notation as I
>do not like using different notation.
>
>After using macrodefs for a little while I and other
>people became aware that ant uses properties for
>passing information between tasks and only having
>non-mutable properties reduce the usefulness of
>macrodefs a lot.
>
>One can use ant-contrib's propertyregex and (via antelope)
>var, and just overwrite properties - but this felt
>like a big hack.
>
>So one week-end I said what the heck and attempted to
>implement local properties. It when through a number
>of iterations.
>
>When this was done, I realized that attributes could
>be implemented by local properties and the problems
>with notation would go away.
>
>This interpretation of reality was not (to say the
>least) universally accepted.
>
>After the 1000'th e-mail explaining what was wrong
>with this, I realized that there may be a point
>in the argument.
>
>So now there is two proposals:
>
>1) to change the macrodef attribute notation from ${x}
>to @{x}.
>
>2) add local properties - completely independent from
>macros - but can be used by them. (This is basically
>what the patch implements but without the @{x} notation)
>
>The problem is that as these are serious changes to
>ant internally (in the case of local) and externally
>(new notation for attributes, properties seem not be non-mutable,
>syntax of local), the changes need support from the ant committers.
>
>As the local stuff is so new some would like to exercise it a
>bit is 1.7 before committing to supporting for all time the
>particular implementation and its public interfaces.
>
>Peter
>
&
RE: Ant 1.6 local and macrodef attributes
Not a committer but my votes on Jose's ballots:
1) Vote on @{x} as the syntax for textual substitutions
of attributes in .
+1
2) Vote on , must include decision on syntax,
scope (i.e., passing things on & co., etc.)
I do not think all these have been settle.
0
-Original Message-
From: Jose Alberto Fernandez [mailto:[EMAIL PROTECTED]
Sent: Wed 11/26/2003 6:15 AM
To: Ant Developers List
Cc:
Subject: RE: Ant 1.6 local and macrodef attributes
Here is my proposal for you guys to vote on.
Two completely separate votes:
1) Vote on @{x} as the syntax for textual substitutions
of attributes in .
Once this is settle, we can move on releasing
in B3 with its fixed syntax.
2) Vote on , must include decision on syntax,
scope (i.e., passing things on & co., etc.)
I do not think all these have been settle.
If (2) is resolved and acepted on 1.6, then Peter
gets most of what he wants, if not, then at least
we can release move on on the rest of ANT.
Jose Alberto
> From: peter reilly [mailto:[EMAIL PROTECTED]
>
>
> On Wednesday 26 November 2003 11:09, Stefan Bodewig wrote:
> > On Wed, 26 Nov 2003, peter reilly <[EMAIL PROTECTED]> wrote:
> > > a)
> > > I sent a vote last week on local properties
> > > and the result was:
> > >committers others (+ votes in
> bugzilla)
> > >have local in ant 1.6 2 1 + 6
> > >not 0 0
> > >+0 1 0
> > >
> > > Based on this and other feedback I think that local does
> belong in
> > > ant 1.6.
> >
> > I agree with your opinion (that locals should be there,
> after all I'm
> > one of the two +1s), but disagree with the conclusion that this is
> > going to happen. 2 +1s is simply not enough to make a vote pass.
> >
> > I'm not trying to argue from a procedural standpoint but
> merely from
> > the fact that a change like this needs community support - and it
> > doesn't seem to have it.
>
> Well as least not Yet..
> >
> > > b)
> > > I send an vote the week before about local properties being
> >
> > s/local properties/macrodef attributes/
>
> Opps..
>
> >
> > > implemented by textual replacement or by using local
> properties. The
> > > result was:
> > >
> > >committers others
> > >local properties2 1
> > >textual replacement 1 4
> > >+0 1 0
> > >
> > > I would like to implement attributes using local properties,
> >
> > -0.8
>
> Ok, The reason (as I said before) I do not like textual subs
> is the use of a different notation.., but I can live with it
> if other people think it is a good thing,
>
> >
> > most if not all things that could be done when we implement the
> > attributes as local properties are possible with textual expansion.
> > Textual expansion enables things that local properties don't.
>
> This is true.
>
> >
> > > I propose to commit local properties and implement
> attributes using
> > > local properties for the ant 1.6 beta3 release.
> >
> > -1 on both. Both parts lack committer support. We could try to
> > revote or something.
>
> Indeed.
>
> Peter
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Ant 1.6 local and macrodef attributes
Here is my proposal for you guys to vote on.
Two completely separate votes:
1) Vote on @{x} as the syntax for textual substitutions
of attributes in .
Once this is settle, we can move on releasing
in B3 with its fixed syntax.
2) Vote on , must include decision on syntax,
scope (i.e., passing things on & co., etc.)
I do not think all these have been settle.
If (2) is resolved and acepted on 1.6, then Peter
gets most of what he wants, if not, then at least
we can release move on on the rest of ANT.
Jose Alberto
> From: peter reilly [mailto:[EMAIL PROTECTED]
>
>
> On Wednesday 26 November 2003 11:09, Stefan Bodewig wrote:
> > On Wed, 26 Nov 2003, peter reilly <[EMAIL PROTECTED]> wrote:
> > > a)
> > > I sent a vote last week on local properties
> > > and the result was:
> > >committers others (+ votes in
> bugzilla)
> > >have local in ant 1.6 2 1 + 6
> > >not 0 0
> > >+0 1 0
> > >
> > > Based on this and other feedback I think that local does
> belong in
> > > ant 1.6.
> >
> > I agree with your opinion (that locals should be there,
> after all I'm
> > one of the two +1s), but disagree with the conclusion that this is
> > going to happen. 2 +1s is simply not enough to make a vote pass.
> >
> > I'm not trying to argue from a procedural standpoint but
> merely from
> > the fact that a change like this needs community support - and it
> > doesn't seem to have it.
>
> Well as least not Yet..
> >
> > > b)
> > > I send an vote the week before about local properties being
> >
> > s/local properties/macrodef attributes/
>
> Opps..
>
> >
> > > implemented by textual replacement or by using local
> properties. The
> > > result was:
> > >
> > >committers others
> > >local properties2 1
> > >textual replacement 1 4
> > >+0 1 0
> > >
> > > I would like to implement attributes using local properties,
> >
> > -0.8
>
> Ok, The reason (as I said before) I do not like textual subs
> is the use of a different notation.., but I can live with it
> if other people think it is a good thing,
>
> >
> > most if not all things that could be done when we implement the
> > attributes as local properties are possible with textual expansion.
> > Textual expansion enables things that local properties don't.
>
> This is true.
>
> >
> > > I propose to commit local properties and implement
> attributes using
> > > local properties for the ant 1.6 beta3 release.
> >
> > -1 on both. Both parts lack committer support. We could try to
> > revote or something.
>
> Indeed.
>
> Peter
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Ant 1.6 local and macrodef attributes
On Wednesday 26 November 2003 11:09, Stefan Bodewig wrote: > On Wed, 26 Nov 2003, peter reilly <[EMAIL PROTECTED]> wrote: > > a) > > I sent a vote last week on local properties > > and the result was: > >committers others (+ votes in bugzilla) > >have local in ant 1.6 2 1 + 6 > >not 0 0 > >+0 1 0 > > > > Based on this and other feedback I think that local does > > belong in ant 1.6. > > I agree with your opinion (that locals should be there, after all I'm > one of the two +1s), but disagree with the conclusion that this is > going to happen. 2 +1s is simply not enough to make a vote pass. > > I'm not trying to argue from a procedural standpoint but merely from > the fact that a change like this needs community support - and it > doesn't seem to have it. Well as least not Yet.. > > > b) > > I send an vote the week before about local properties being > > s/local properties/macrodef attributes/ Opps.. > > > implemented by textual replacement or by using local properties. > > The result was: > > > >committers others > >local properties2 1 > >textual replacement 1 4 > >+0 1 0 > > > > I would like to implement attributes using local properties, > > -0.8 Ok, The reason (as I said before) I do not like textual subs is the use of a different notation.., but I can live with it if other people think it is a good thing, > > most if not all things that could be done when we implement the > attributes as local properties are possible with textual expansion. > Textual expansion enables things that local properties don't. This is true. > > > I propose to commit local properties and implement attributes using > > local properties for the ant 1.6 beta3 release. > > -1 on both. Both parts lack committer support. We could try to > revote or something. Indeed. Peter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Ant 1.6 local and macrodef attributes
On Wednesday 26 November 2003 10:31, Jose Alberto Fernandez wrote:
> > From: peter reilly [mailto:[EMAIL PROTECTED]
> >
> > b)
> > I send an vote the week before about local properties being
> > implemented by textual replacement or by using local
> > properties. The result was:
>
> The vote was about macrodef expanding attributes as local properties.
Opps
> Just to make things clear.
>
> >committers others
> >local properties2 1
> >textual replacement 1 4
> >+0 1 0
> >
> >
> > I would like to implement attributes using local properties,
> > with a possible option to allow the script writer to specify
> > textual replacement.
>
> You are the committers and you do whatever you want, but I think this
> is the biggest mistake that you can make to ANT (using locals).
Point taken..
> Providing both, sounds even more confusing. It means you get the
> bad side effects no matter what. (Or will I be able to say "DO NOT USE
> LOCALS AT ALL"?)
> If that is the case, then at least make it the default.
>
> > c)
> > I sent a vote on the syntax to use for texual replacement.
> > There was a varied response. A number of people liked the
> > notation @{x}.
>
> That looks fine to me.
>
> > -
> >
> > I propose to commit local properties and implement attributes
> > using local properties for the ant 1.6 beta3 release.
> >
> > If there are problems with use of local properties as
> > attributes, this should be discovered very quickly.
>
> I thought we discover them already.
>
> Jose Alberto
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Ant 1.6 local and macrodef attributes
On Wed, 26 Nov 2003, peter reilly <[EMAIL PROTECTED]> wrote: > a) > I sent a vote last week on local properties > and the result was: >committers others (+ votes in bugzilla) >have local in ant 1.6 2 1 + 6 >not 0 0 >+0 1 0 > > Based on this and other feedback I think that local does > belong in ant 1.6. I agree with your opinion (that locals should be there, after all I'm one of the two +1s), but disagree with the conclusion that this is going to happen. 2 +1s is simply not enough to make a vote pass. I'm not trying to argue from a procedural standpoint but merely from the fact that a change like this needs community support - and it doesn't seem to have it. > b) > I send an vote the week before about local properties being s/local properties/macrodef attributes/ > implemented by textual replacement or by using local properties. > The result was: > >committers others >local properties2 1 >textual replacement 1 4 >+0 1 0 > > I would like to implement attributes using local properties, -0.8 most if not all things that could be done when we implement the attributes as local properties are possible with textual expansion. Textual expansion enables things that local properties don't. > I propose to commit local properties and implement attributes using > local properties for the ant 1.6 beta3 release. -1 on both. Both parts lack committer support. We could try to revote or something. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Ant 1.6 local and macrodef attributes
> From: peter reilly [mailto:[EMAIL PROTECTED]
>
> b)
> I send an vote the week before about local properties being
> implemented by textual replacement or by using local
> properties. The result was:
>
The vote was about macrodef expanding attributes as local properties.
Just to make things clear.
>committers others
>local properties2 1
>textual replacement 1 4
>+0 1 0
>
>
> I would like to implement attributes using local properties,
> with a possible option to allow the script writer to specify
> textual replacement.
>
You are the committers and you do whatever you want, but I think this
is the biggest mistake that you can make to ANT (using locals).
Providing both, sounds even more confusing. It means you get the
bad side effects no matter what. (Or will I be able to say "DO NOT USE
LOCALS AT ALL"?)
If that is the case, then at least make it the default.
>
> c)
> I sent a vote on the syntax to use for texual replacement.
> There was a varied response. A number of people liked the
> notation @{x}.
>
That looks fine to me.
> -
>
> I propose to commit local properties and implement attributes
> using local properties for the ant 1.6 beta3 release.
>
> If there are problems with use of local properties as
> attributes, this should be discovered very quickly.
>
I thought we discover them already.
Jose Alberto
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Ant 1.6 local and macrodef attributes
a)
I sent a vote last week on local properties
and the result was:
committers others (+ votes in bugzilla)
have local in ant 1.6 2 1 + 6
not 0 0
+0 1 0
Based on this and other feedback I think that local does
belong in ant 1.6.
There was some concern about the syntax of declaring local
as a standalone task as against having a localproperty container.
I do not share the concern.
b)
I send an vote the week before about local properties being
implemented by textual replacement or by using local properties.
The result was:
committers others
local properties2 1
textual replacement 1 4
+0 1 0
I would like to implement attributes using local properties, with
a possible option to allow the script writer to specify textual replacement.
c)
I sent a vote on the syntax to use for texual replacement. There was a varied
response. A number of people liked the notation @{x}.
-
I propose to commit local properties and implement attributes using local
properties for the ant 1.6 beta3 release.
If there are problems with use of local properties as attributes, this should
be discovered very quickly.
Peter
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
