RE: Ant 1.6 local and macrodef attributes
moving this discussion to ant dev list and including Jacob Kjome
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 macrodef. The whole
business with the scope of properties is already complicated enough. The
local patch or something like it will be necessary to solve your use case.
But is local 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 antcall call.
Textual substitution destroys that. A macrodef 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 local. We just add one
level of indirection.
Instead of this:
macrodef name=A
attribute name=test.file/
sequential
available property=file.available value = yes file=@{test.file}/
property name=file.available value=no/
echoIs @{test.file} available? ${file.available}./echo
/sequential
/macrodef
...
A test.file=foo.bar/
...
A test.file=bar.food/
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:
macrodef name=A2
attribute name=test.file/
attribute name=available.prop/
sequential
available property=@{available.prop}
value = yes
file=@{test.file}/
property name=@{available.prop} value=no/
echoIs @{test.file} available? [EMAIL PROTECTED]/echo
/sequential
/macrodef
...
A2 test.file=foo.bar available.prop=foo.bar.available/
...
A2 test.file=bar.food available.prop=peanuts.available/
This is annoyingly less simple than local but still allows macrodef 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-devm=106993855725136w=2
Seems that Stefan liked it...
http://marc.theaimsgroup.com/?l=ant-devm=106994393230831w=2
So, I guess that means that proposal #1 below is going to be implemented
for Ant-1.6. However, does this still leave local 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...
macrodef name=A
attribute name=test.file/
sequential
local name=file.available/ !-- this is the part that makes
this macrodef non-useless. --
available property=file.available value = yes
file=@{test.file}/
property name=file.available value=no/
echoIs @{test.file} available? ${file.available}./echo
/sequential
/macrodef
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-devr=1w=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
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:
moving this discussion to ant dev list and including Jacob Kjome
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 macrodef. The whole
business with the scope of properties is already complicated enough. The
local patch or something like it will be necessary to solve your use
case. But is local 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
antcall call. Textual substitution destroys that. A macrodef 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 local. We
just add one level of indirection.
Instead of this:
macrodef name=A
attribute name=test.file/
sequential
available property=file.available value = yes
file=@{test.file}/
property name=file.available value=no/
echoIs @{test.file} available? ${file.available}./echo
/sequential
/macrodef
...
A test.file=foo.bar/
...
A test.file=bar.food/
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:
macrodef name=A2
attribute name=test.file/
attribute name=available.prop/
sequential
available property=@{available.prop}
value = yes
file=@{test.file}/
property name=@{available.prop} value=no/
echoIs @{test.file} available? [EMAIL PROTECTED]/echo
/sequential
/macrodef
...
A2 test.file=foo.bar available.prop=foo.bar.available/
...
A2 test.file=bar.food available.prop=peanuts.available/
This is annoyingly less simple than local but still allows macrodef 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-devm=106993855725136w=2http://marc.theaimsgroup.com/?l=ant-devm=106993855725136w=2
Seems that Stefan liked it...
http://marc.theaimsgroup.com/?l=ant-devm=106994393230831w=2http://marc.theaimsgroup.com/?l=ant-devm=106994393230831w=2
So, I guess that means that proposal #1 below is going to be implemented
for Ant-1.6. However, does this still leave local 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...
macrodef name=A
attribute name=test.file/
sequential
local name=file.available/ !-- this is the part that makes
this macrodef non-useless. --
available property=file.available value = yes
file=@{test.file}/
property name=file.available value=no/
echoIs @{test.file} available? ${file.available}./echo
/sequential
/macrodef
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-devr=1w=2http://marc.theaimsgroup
.com/?l=ant-devr=1w=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
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]
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 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
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 macrodef.
Once this is settle, we can move on releasing macrodef
in B3 with its fixed syntax.
2) Vote on local, must include decision on syntax,
scope (i.e., passing things on ant 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
Not a committer but my votes on Jose's ballots:
1) Vote on @{x} as the syntax for textual substitutions
of attributes in macrodef.
+1
2) Vote on local, must include decision on syntax,
scope (i.e., passing things on ant 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 macrodef.
Once this is settle, we can move on releasing macrodef
in B3 with its fixed syntax.
2) Vote on local, must include decision on syntax,
scope (i.e., passing things on ant 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]
