Property expansion in macrodef attributes
Hi all,
for those who don't follow bugzilla comment threads (I know I seldomly
do):
Until Ant 1.8.2 ${} sequences in macrodef attributes were expanded once
before @{} sequences are expanded and once in the context where the @{}
is expanded. I.e. with
macrodef name=propertycopy
attribute name=name/
attribute name=from/
sequential
property name=@{name} value=${@{from}}/
/sequential
/macrodef
property name=choice value=2/
property name=thing.1 value=one/
property name=thing.2 value=two/
property name=thing.3 value=three/
propertycopy to=thing from=thing.${choice}/
@{from} becomes thing.2 and the second expansion does what the FAQ says.
Ant's trunk has removed the ${} expansion that happens before @{}
expansion, breaking the example of our own FAQ and breaking some other
existing macrodefs out there (for example in Netbeans).
https://issues.apache.org/bugzilla/show_bug.cgi?id=52621
Double expansion is unexpected and leads to subtle issues:
https://issues.apache.org/bugzilla/show_bug.cgi?id=42046
https://issues.apache.org/bugzilla/show_bug.cgi?id=41400
In particular it made some AntUnit tests pass in Ant's own code base
even though the code was actually broken.
Jesse suggests to introduce an attribute to macrodef (or even at the
granularity of the individual attribute definition of a macrodef) to
control ${} expansion.
I'm not sure whether the macrodef writer will always know whether she
wants double-expansion or not. I also fear it will be quite difficult
to explain in the manual of a macrodefed task (this attribute may have
${} sequences expanded twice, this other one will not).
Another option would be to not fix the 1.8.2 behavior at all but call it
a feature. Macrodef writers then can say something like foo is
implemented as a macrodef so ${} will be expanded twice, see
http://ant.apache.org/faq.html#macrodef-property-expansion - not sure
whether this a good option.
Any other ideas?
Stefan
-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org
Regarding exec task
Hi, I noticed that on windows, if I use the exec task to run a batch script which in turn starts other processes then if kill ant then the sub-processes created by the batch script still continues to run. I did some research on google and found that the default java implementation of Process.destroy does not kill the child processes created by a process on windows. I also found that there are some third party libraries like jvnet that provide the capability of killing all processes created by a process on windows. So I thought of somehow extending the 'Execute' class of ant to use the functionality of this 3rd party library, but I find that its difficult if not impossible to extend this class. I can't find a way to provide my implementation of Process class that does something different when its destroy method is called. Other core tasks such as java task directly create an instance of the 'Execute' class which makes it difficult to globally change how a forked process is destroyed within ant. Is it possible to make the Execute class in ant extensible so that it becomes possible to plugin our own implementation of Process class. Thanks Vimil
Re: Regarding exec task
Is it possible to make the Execute class in ant extensible so that it becomes possible to plugin our own implementation of Process class. Implement your own ueber-exec taks which uses default exec class when not-on windows and otherwise makes use of your own jvnet-process exec task. On Sun, Feb 12, 2012 at 3:29 PM, Vimil Saju vimils...@yahoo.com wrote: Hi, I noticed that on windows, if I use the exec task to run a batch script which in turn starts other processes then if kill ant then the sub-processes created by the batch script still continues to run. I did some research on google and found that the default java implementation of Process.destroy does not kill the child processes created by a process on windows. I also found that there are some third party libraries like jvnet that provide the capability of killing all processes created by a process on windows. So I thought of somehow extending the 'Execute' class of ant to use the functionality of this 3rd party library, but I find that its difficult if not impossible to extend this class. I can't find a way to provide my implementation of Process class that does something different when its destroy method is called. Other core tasks such as java task directly create an instance of the 'Execute' class which makes it difficult to globally change how a forked process is destroyed within ant. Is it possible to make the Execute class in ant extensible so that it becomes possible to plugin our own implementation of Process class. Thanks Vimil -- Wolfgang Häfelinger - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: Property expansion in macrodef attributes
On 02/12/2012 05:13 AM, Stefan Bodewig wrote:
I'm not sure whether the macrodef writer will always know whether she
wants double-expansion or not.
I would say that if you come across a problem like that mentioned in #42046
then you know you do not want double expansion and should explicitly turn it
off.
In most cases the script calling the macro will be the same as the script defining it, or at least located in the same project, so I doubt documentation of the macrodef
is an issue; though discoverability of the flag in the macrodef task may be poor even with a FAQ entry.
If this problem had been noticed when macrodef was first introduced, then single expansion would be the more intuitive behavior, especially if #29347 were fixed properly
so that ${thing.${choice}} works the way people expect it to, but it is too late to change the default behavior of macrodef.
-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org
