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]