RE: macrodef - do attributes as properties or substitutions
From: Steve Cohen [mailto:[EMAIL PROTECTED] I have used a similar idea with a build file full of template targets that use a fileset reference. The reference must be defined globally or the build will break, but only some of the users of the file of templates actually need the reference. So, since references can be overridden, the solution is, similar to Stefan's, fileset id=globaltlds dir=. include name=no.real.file/ /fileset Later, a user of this buildfile can redefine the globaltlds reference, if it needs to, to something real. Yeah, this sounds a lot like the Null Object idiom you can read about in Martin Fowler's Refactoring book. OTOH, now that there is the isreference condition, a cleaner approach might be to conditionaly execute the target only of the reference is defined at all, rather than defining a null/dummy one. Probably not applicable all the time, but still. --DD - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: macrodef - do attributes as properties or substitutions
True, that was from the 1.4/1.5 days. -Original Message- From: Dominique Devienne [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 19, 2003 8:52 AM To: 'Ant Developers List' Subject: RE: macrodef - do attributes as properties or substitutions From: Steve Cohen [mailto:[EMAIL PROTECTED] I have used a similar idea with a build file full of template targets that use a fileset reference. The reference must be defined globally or the build will break, but only some of the users of the file of templates actually need the reference. So, since references can be overridden, the solution is, similar to Stefan's, fileset id=globaltlds dir=. include name=no.real.file/ /fileset Later, a user of this buildfile can redefine the globaltlds reference, if it needs to, to something real. Yeah, this sounds a lot like the Null Object idiom you can read about in Martin Fowler's Refactoring book. OTOH, now that there is the isreference condition, a cleaner approach might be to conditionaly execute the target only of the reference is defined at all, rather than defining a null/dummy one. Probably not applicable all the time, but still. --DD - 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: macrodef - do attributes as properties or substitutions
macrodef name=macro attribute name=one/ attribute name=two default=${one}/ /macrodef macro one=hello/ I don't think we should need any special cludges just to support this usecase. 8-) Give two a completely bogus, impossible to be used in any real world usage value and check for that. Should be easier than comparing it to a literal ${one} or @one or whathever. macrodef name=macro attribute name=one/ attribute name=two default=nobody-with-a-sane-mind-would-ever-want-to-use-this-value/ /macrodef Nice idea - usually such nice words don´t come into my mind when I´m programming :-) But the string comparison would be easier. Jan
RE: macrodef - do attributes as properties or substitutions
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 18, 2003 2:06 AM To: [EMAIL PROTECTED] Subject: RE: macrodef - do attributes as properties or substitutions macrodef name=macro attribute name=one/ attribute name=two default=${one}/ /macrodef macro one=hello/ I don't think we should need any special cludges just to support this usecase. 8-) Give two a completely bogus, impossible to be used in any real world usage value and check for that. Should be easier than comparing it to a literal ${one} or @one or whathever. macrodef name=macro attribute name=one/ attribute name=two default=nobody-with-a-sane-mind-would-ever-want-to-use-this-value/ /macrodef Nice idea - usually such nice words don´t come into my mind when I´m programming :-) But the string comparison would be easier. Jan I have used a similar idea with a build file full of template targets that use a fileset reference. The reference must be defined globally or the build will break, but only some of the users of the file of templates actually need the reference. So, since references can be overridden, the solution is, similar to Stefan's, fileset id=globaltlds dir=. include name=no.real.file/ /fileset Later, a user of this buildfile can redefine the globaltlds reference, if it needs to, to something real. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: macrodef - do attributes as properties or substitutions
On Fri, 14 Nov 2003, peter reilly [EMAIL PROTECTED] wrote: On Friday 14 November 2003 14:07, Stefan Bodewig wrote: On Fri, 14 Nov 2003, peter reilly [EMAIL PROTECTED] wrote: I do not like using a different notation for attributes. unless they are a different thing than properties, if I understand you correctly. Not quite, I mean that if they are differnet from properties, a different notation should be used, but I do not like using a different notation in principle. Message understaood, thanks. An example: target name=s macrodef name=show element name=x/ sequential property name=inmacro value=Set in macro/ x/ /sequential /macrodef show x echoinmacro is '${inmacro}'/echo /x /show /target This shows: s: inmacro is 'Set in macro' It would be very difficult to stop this. So we must ask outselves whether this is good or bad for us. If the property inmacro has been defined before the macro invocation, the task inside the macro will be a noop - the user gets the expected behavior. If it has not been set, well, this might come unexpected. But there will never be any double expansion, right? I mean, echoinmacro is '$${inmacro}'/echo would always result in s: inmacro is '${inmacro}' Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: macrodef - do attributes as properties or substitutions
On Fri, 14 Nov 2003, Jan Materne [EMAIL PROTECTED] wrote: macrodef name=macro attribute name=one/ attribute name=two default=${one}/ /macrodef macro one=hello/ I don't think we should need any special cludges just to support this usecase. 8-) Give two a completely bogus, impossible to be used in any real world usage value and check for that. Should be easier than comparing it to a literal ${one} or @one or whathever. macrodef name=macro attribute name=one/ attribute name=two default=nobody-with-a-sane-mind-would-ever-want-to-use-this-value/ /macrodef Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: macrodef - do attributes as properties or substitutions
On Monday 17 November 2003 15:57, Stefan Bodewig wrote: On Fri, 14 Nov 2003, peter reilly [EMAIL PROTECTED] wrote: An example: target name=s macrodef name=show element name=x/ sequential property name=inmacro value=Set in macro/ x/ /sequential /macrodef show x echoinmacro is '${inmacro}'/echo /x /show /target This shows: s: inmacro is 'Set in macro' It would be very difficult to stop this. So we must ask outselves whether this is good or bad for us. If the property inmacro has been defined before the macro invocation, the task inside the macro will be a noop - the user gets the expected behavior. If it has not been set, well, this might come unexpected. I suppose it depends on how one sees macrodef. Treated as a simple macro substition: macrodef name=show element name=x/ sequential property name=inmacro value=Set in macro/ x/ /sequential /macrodef target name=s show x echoinmacro is '${inmacro}'/echo /x /show /target the target s would become: target name=s sequential property name=inmacro value=Set in macro/ echoinmacro is '${inmacro}'/echo /sequential /target And the above will behave the same as the macrodef version. But there will never be any double expansion, right? I mean, echoinmacro is '$${inmacro}'/echo would always result in s: inmacro is '${inmacro}' Yes with the current implementation (not with some of my intermediate implementations...) Peter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: macrodef - do attributes as properties or substitutions
On Wed, 12 Nov 2003, Jose Alberto Fernandez [EMAIL PROTECTED] wrote: [scriptdef and beanshell] Line numbers never match with that of the srcfiles. But back to the topic. Looks as if Peter sees the same - a BSF problem of not passing the correct line number in? I want macrodef for when all I need to do is to put toguether a group of calls to other tasks in a sequence, which could be quite complex, but it does not require any additional computation from my part: And I don't want to take that away - neither from you nor anybody else 8-) From: Stefan Bodewig [mailto:[EMAIL PROTECTED] In which situation would atributes modify properties have negative effects on what you are planing to do with macrodef? Do you have an enlightening example? [attribute is called debug and would shadow a debug property] presetdef name=my.javac javac srcdir=src destdir=classes deprecation=${deprecation} debug=${debug}/ /presetdef I'd expect that the properties have been expanded at the point of presetdef already so there shouldn't be any shadow affecting that definition. No here the intention of the code writer was to control javac using the debug property. But just because I decided to write myMacro with an attribute called debug, I am changing the behavior of my.java. (if we use locals) Only if the expansion of properties in presetdef is performed in the scope of the macro invocation and not at definition time. But we could simple use your example with myMacro debug=true code echo${debug}/echo /code /myMacro and ask ourselves what the user wanted to say here. I agree that we remove the ambiguity when attributes are not properties. But wait, what if I actually wanted to change the property? Well, in that case you can introduce the local yourself as part of the code of the macro: I knew you'd say that (and I even came to this conclusion all by myself already ;-). Peter, Jan, now that we've seen Jose Alberto's use case - what can macrodef do when we use (local) properties that can't be done with textual substitutions? I may be willing to swallow local in 1.6 even if macrodef attributes don't use it. The main problems other languages have with macros as textual replacements (i.e. Lisp's defmacro or C's #define) is that the expression you pass in may be evaluated more than one. I.e. #define square(x) x * x and used as square(i++) may lead to unexpected results. The only expression evaluation we have in Ant is property expansion and that would have been performed before the value of the attribute gets used - and exactly once - no matter how we implement it, wouldn't it? Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: macrodef - do attributes as properties or substitutions
On Friday 14 November 2003 10:53, Stefan Bodewig wrote: presetdef name=my.javac javac srcdir=src destdir=classes deprecation=${deprecation} debug=${debug}/ /presetdef I'd expect that the properties have been expanded at the point of presetdef already so there shouldn't be any shadow affecting that definition. presetdef expands the properties at the point of use, not at the point of definition. No here the intention of the code writer was to control javac using the debug property. But just because I decided to write myMacro with an attribute called debug, I am changing the behavior of my.java. (if we use locals) Only if the expansion of properties in presetdef is performed in the scope of the macro invocation and not at definition time. But we could simple use your example with myMacro debug=true code echo${debug}/echo /code /myMacro and ask ourselves what the user wanted to say here. I agree that we remove the ambiguity when attributes are not properties. But wait, what if I actually wanted to change the property? Well, in that case you can introduce the local yourself as part of the code of the macro: I knew you'd say that (and I even came to this conclusion all by myself already ;-). Peter, Jan, now that we've seen Jose Alberto's use case - what can macrodef do when we use (local) properties that can't be done with textual substitutions? I may be willing to swallow local in 1.6 even if macrodef attributes don't use it. I do not like using a different notation for attributes. After programming in perl for many years, (many years ago), I came to hate the different notations for arrays, scalars, maps, and ?Files?. However, if attributes are done by textual notation, they should have a different notation. myMacro debug=true code echo$(debug) is not ${debug}/echo /code /myMacro Other than that, there is not much differnce. Retaining the ${} format (implying using local properties) would be a benefit, in that porting of antcall's would be easier. If attributes are local properties, there is an issue with shadowing of user properties. In the above case, it is common for people to do ant -Ddebug=no ... The main problems other languages have with macros as textual replacements (i.e. Lisp's defmacro or C's #define) is that the expression you pass in may be evaluated more than one. I.e. #define square(x) x * x and used as square(i++) may lead to unexpected results. The only expression evaluation we have in Ant is property expansion and that would have been performed before the value of the attribute gets used - and exactly once - no matter how we implement it, wouldn't it? Not quite, the expansion gets performed just before a task is run, and with macrodef and presetdef, the UE's are stored and (for macrodef's case) copied. If the expansion is done by macrodef/presetdef, it is difficult to stop the expansion being done again later. It had a version of RuntimeConfigureable with kept track of the expansion, but this does not work for expansion done by tasks for addText(). Peter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: macrodef - do attributes as properties or substitutions
From: Stefan Bodewig [mailto:[EMAIL PROTECTED] On Wed, 12 Nov 2003, Jose Alberto Fernandez [EMAIL PROTECTED] wrote: From: Stefan Bodewig [mailto:[EMAIL PROTECTED] In which situation would atributes modify properties have negative effects on what you are planing to do with macrodef? Do you have an enlightening example? [attribute is called debug and would shadow a debug property] presetdef name=my.javac javac srcdir=src destdir=classes deprecation=${deprecation} debug=${debug}/ /presetdef I'd expect that the properties have been expanded at the point of presetdef already so there shouldn't be any shadow affecting that definition. I knew something like this will be in the answer ;-/ But never mind, my only point here is that the user of my.javac will not see the connection between the attribute and the behavior of the task. You cound achive the same example by having: macrodef name=my.javac element name=fileset/ sequential javac srcdir=src destdir=classes deprecation=${deprecation} debug=${debug} fileset/ /javac /sequential /macrodef So here the properties should be expanded at execution time. And my comments are the same. They also apply to java tasks that use properties internally. None of our container tasks have such behavior. For example when I write: parallel failonany=true echo${failonany}/echo parallel there is no expectation that a property called failonany will show up just because I use an attribute of that name. But if parallel was implemented using a macro, then you get this behavior. So now, when you use some code from some antlib somewhere, or you import some build fragment. Now you need to be aware of whether the task you want to use was an actual java task (that does not messup your properties) or is some macro-defined task that will mess up your properties with the names of all the attributes that you pass and the names of any other attributes of any other macros that that macro calls before it calls your elements. Who will understand what is going on on a large project? It will be just a mess with no benefit what so ever. Is my hyperbole compelling enough? :-) Jose Alberto - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: macrodef - do attributes as properties or substitutions
I came from the users point of view. More exactly while writing access code inside a script task. macrodef attribute sequential script HERE PLAYS THE MUSIC :-) /script /sequential /macrodef And the question was: how can I access the attribute-value? If you write inside a target that would be value = project.getProperty(name); But not here. So development / copying the code from somewhere else / refactor that code out would be more diffult. Difficult but not impossible: value = ${value}; would do that (or the other bracket type). But the textual expansion has another disadvantage: if (parameter == ${name}) set-default-for-parameter; You can´t do that ... (mmh maybe nevertheless, not enought thought about that). So the workaround would be splitting the string ${name} to ${na+me}. All can be done. But not in a nice and uniform way. That´s why I prefer local properties. Jan
Re: macrodef - do attributes as properties or substitutions
On Fri, 14 Nov 2003, peter reilly [EMAIL PROTECTED] wrote: presetdef expands the properties at the point of use, not at the point of definition. Better note that somewhere prominently. On Friday 14 November 2003 10:53, Stefan Bodewig wrote: Peter, Jan, now that we've seen Jose Alberto's use case - what can macrodef do when we use (local) properties that can't be done with textual substitutions? I do not like using a different notation for attributes. unless they are a different thing than properties, if I understand you correctly. Other than that, there is not much differnce. Retaining the ${} format (implying using local properties) would be a benefit, in that porting of antcall's would be easier. OK. If attributes are local properties, there is an issue with shadowing of user properties. Actually, shadowing any properties, but that's an issue of local in general. The only expression evaluation we have in Ant is property expansion and that would have been performed before the value of the attribute gets used - and exactly once - no matter how we implement it, wouldn't it? Not quite, the expansion gets performed just before a task is run, and with macrodef and presetdef, the UE's are stored and (for macrodef's case) copied. If the expansion is done by macrodef/presetdef, it is difficult to stop the expansion being done again later. At what stage? I mean, is the a way that property name=foo value=${bar}/ property name=bar value=baz/ was defined and a text of ${foo} somewhere inside a macro (pr presetdefed task) would end up being resolved to baz? I.e. is it possible that the same string undergoes macro expansion more than once? Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: macrodef - do attributes as properties or substitutions
On Fri, 14 Nov 2003, Jan Materne [EMAIL PROTECTED] wrote: And the question was: how can I access the attribute-value? @attribute or $(attribute) or - as long as we use a different notation we don't have to fear that we'd accidently clash with properties or scripting language constructs. If you write inside a target that would be value = project.getProperty(name); But not here. Neither is it in scriptdef for example. If we say that the attribute doesn't turn into a property - and don't make it look like one - people won't expect they could get at it via project.getProperty. But the textual expansion has another disadvantage: if (parameter == ${name}) set-default-for-parameter; You can´t do that ... I'm afraid you've lost me. What is the issue you are having here? Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: macrodef - do attributes as properties or substitutions
On Friday 14 November 2003 14:07, Stefan Bodewig wrote: On Fri, 14 Nov 2003, peter reilly [EMAIL PROTECTED] wrote: presetdef expands the properties at the point of use, not at the point of definition. Better note that somewhere prominently. Ok. On Friday 14 November 2003 10:53, Stefan Bodewig wrote: Peter, Jan, now that we've seen Jose Alberto's use case - what can macrodef do when we use (local) properties that can't be done with textual substitutions? I do not like using a different notation for attributes. unless they are a different thing than properties, if I understand you correctly. Not quite, I mean that if they are differnet from properties, a different notation should be used, but I do not like using a different notation in principle. Other than that, there is not much differnce. Retaining the ${} format (implying using local properties) would be a benefit, in that porting of antcall's would be easier. OK. If attributes are local properties, there is an issue with shadowing of user properties. Actually, shadowing any properties, but that's an issue of local in general. The only expression evaluation we have in Ant is property expansion and that would have been performed before the value of the attribute gets used - and exactly once - no matter how we implement it, wouldn't it? Not quite, the expansion gets performed just before a task is run, and with macrodef and presetdef, the UE's are stored and (for macrodef's case) copied. If the expansion is done by macrodef/presetdef, it is difficult to stop the expansion being done again later. At what stage? I mean, is the a way that property name=foo value=${bar}/ property name=bar value=baz/ was defined and a text of ${foo} somewhere inside a macro (pr presetdefed task) would end up being resolved to baz? I.e. is it possible that the same string undergoes macro expansion more than once? An example: target name=s macrodef name=show element name=x/ sequential property name=inmacro value=Set in macro/ x/ /sequential /macrodef show x echoinmacro is '${inmacro}'/echo /x /show /target This shows: s: inmacro is 'Set in macro' It would be very difficult to stop this. Peter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: macrodef - do attributes as properties or substitutions
On Tue, 11 Nov 2003, Jose Alberto Fernandez [EMAIL PROTECTED] wrote: To me macrodefs are for writing all those tasks that I am too lazy, or they are too simple for me to need to go and write and maintain some Java code. I'm not sure that this is the intention of macrodef - maybe you would rather use scriptdef with beanshell as your scripting language then? Substitution is the least interfearing behavior. I hear you and to a certain degree I agree with you. Actually I haven't really made up my mind myself yet - no vote from me so far. But if atributes modify properties, then there is no way for me to stop them for happening. In which situation would atributes modify properties have negative effects on what you are planing to do with macrodef? Do you have an enlightening example? Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: macrodef - do attributes as properties or substitutions
On Tuesday 11 November 2003 19:01, Jose Alberto Fernandez wrote: BTW, how this things will affect the other tasks derived from macrodef like presetdef? Although they were introduced at the same time and in some ways are similar, presetdef is not derived from macrodef. Note that a recent change to presetdef has made it more usefull. Originally if the same attributes where in the preset and then reset in the script, the attributes in question would be set twice. This causes some grief. The implementation now (in cvs and the next 1.6 beta), treats the attributes as default values which may be overridden when used. For example: presetdef name=my.javac javac srcdir=src destdir=classes deprecation=${deprecation} debug=${debug}/ /presetdef my.javac srcdir=test/src .../ now works as expected. Peter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: macrodef - do attributes as properties or substitutions
From: Stefan Bodewig [mailto:[EMAIL PROTECTED] On Tue, 11 Nov 2003, Jose Alberto Fernandez To me macrodefs are for writing all those tasks that I am too lazy, or they are too simple for me to need to go and write and maintain some Java code. I'm not sure that this is the intention of macrodef - maybe you would rather use scriptdef with beanshell as your scripting language then? I do use it extensively. And believe me, every time we have a syntax or logical error in the code it takes 1o times longer to find it. Line numbers never match with that of the srcfiles. But back to the topic. I want macrodef for when all I need to do is to put toguether a group of calls to other tasks in a sequence, which could be quite complex, but it does not require any additional computation from my part: macrodef name=preferential-copy attribute name=app-pref.name/ attribute name=app-pref.dir/ sequential mkdir dir=${app-prefs.dir}/ dependset srcfileset dir=${basedir} include name=${app-prefs.name}/**/ include name=${containers.dir}/${app-prefs.name}/**/ include name=${descriptor.dir.app}/${app-prefs.name}/**/ include name=${descriptor.container.dir.app}/${app-prefs.name}/**/ /srcfileset targetfileset dir=${app-prefs.dir}/ /dependset if available file='${descriptor.container.dir.app}/${app-prefs.name}' type=dir/ then copy todir='${app-prefs.dir}' fileset dir=${descriptor.container.dir.app}/${app-prefs.name} includes=**/ /copy /then /if if available file='${descriptor.dir.app}/${app-prefs.name}' type=dir/ then copy todir='${app-prefs.dir}' fileset dir=${descriptor.dir.app}/${app-prefs.name} includes=**/ /copy /then /if if available file='${containers.dir}/${app-prefs.name}' type=dir/ then copy todir='${app-prefs.dir}' fileset dir=${containers.dir}/${app-prefs.name} includes=**/ /copy /then /if if available file='${app-prefs.name}' type=dir/ then copy todir='${app-prefs.dir}' fileset dir=${app-prefs.name} includes=**/ /copy /then /if /sequential /macrodef Today, I need to do this by calling antcall because I need to pass diferent parameters in different places. It will look much better that instead of: antcall target=prefs.app param name=app-prefs.name value=war-res/ param name=app-prefs.dir value=${war-res.app}/ /antcall I can just say: preferential-copy app-prefs.name=war-res app-prefs.dir=${war-res.app}/ You can see that using scriptdef to do this job is absolute madness. Since all you need is to put toguether some tasks. Substitution is the least interfearing behavior. I hear you and to a certain degree I agree with you. Actually I haven't really made up my mind myself yet - no vote from me so far. But if atributes modify properties, then there is no way for me to stop them for happening. In which situation would atributes modify properties have negative effects on what you are planing to do with macrodef? Do you have an enlightening example? macrodef name=myMacro attribute name=debug/ element name=code/ sequential if istrue value=${debug} then echomyMacro: Entering my macro/echo code/ echomyMacro: Entering my macro/echo /then else code/ /else /if /sequential /macrodef So here we have this simple macro that adds some debug information. So I use it like: myMacro debug=true code my.javac srcdir=test/src .../ /code /myMacro Still, very naïve code. Until you see that the definition of my.java is: presetdef name=my.javac javac srcdir=src destdir=classes deprecation=${deprecation} debug=${debug}/ /presetdef No here the intention of the code writer was to control javac using the debug property. But just because I decided to write myMacro with an attribute called debug, I am changing the behavior of my.java. (if we use locals) If this one is not convinsing enough, I am sure we can build one based on this model. If we were doing replacement, this will not happen. The attribute debug will only affect the if and not the things inside code/. But wait, what if I actually wanted to change the property? Well, in that case you can introduce the local yourself as part of the code of the macro: macrodef name=myMacro attribute name=debug/ element name=code/ sequential local property=debug value=$(debug) if istrue value=${debug} then echomyMacro: Entering my macro/echo code/ echomyMacro: Entering my macro/echo /then else code/ /else
RE: macrodef - do attributes as properties or substitutions
I want macrodef for when all I need to do is to put toguether a group of calls to other tasks in a sequence, which could be quite complex, but it does not require any additional computation from my part Hear, hear! Used in this way, you can use ant, cutting out expensive antcall calls and most taskdef's. I myself have never written a taskdef and don't want to start unless I really have to do something specialized. taskdef's and what they do are a mystery to readers of a build script and IMHO should not be used just to glue targets together in some particular way unless there is a very good reason for it. That's what I want from macrodef. -Original Message- From: Jose Alberto Fernandez [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 12, 2003 12:37 PM To: Ant Developers List Subject: RE: macrodef - do attributes as properties or substitutions From: Stefan Bodewig [mailto:[EMAIL PROTECTED] On Tue, 11 Nov 2003, Jose Alberto Fernandez To me macrodefs are for writing all those tasks that I am too lazy, or they are too simple for me to need to go and write and maintain some Java code. I'm not sure that this is the intention of macrodef - maybe you would rather use scriptdef with beanshell as your scripting language then? I do use it extensively. And believe me, every time we have a syntax or logical error in the code it takes 1o times longer to find it. Line numbers never match with that of the srcfiles. But back to the topic. I want macrodef for when all I need to do is to put toguether a group of calls to other tasks in a sequence, which could be quite complex, but it does not require any additional computation from my part: macrodef name=preferential-copy attribute name=app-pref.name/ attribute name=app-pref.dir/ sequential mkdir dir=${app-prefs.dir}/ dependset srcfileset dir=${basedir} include name=${app-prefs.name}/**/ include name=${containers.dir}/${app-prefs.name}/**/ include name=${descriptor.dir.app}/${app-prefs.name}/**/ include name=${descriptor.container.dir.app}/${app-prefs.name}/**/ /srcfileset targetfileset dir=${app-prefs.dir}/ /dependset if available file='${descriptor.container.dir.app}/${app-prefs.name}' type=dir/ then copy todir='${app-prefs.dir}' fileset dir=${descriptor.container.dir.app}/${app-prefs.name} includes=**/ /copy /then /if if available file='${descriptor.dir.app}/${app-prefs.name}' type=dir/ then copy todir='${app-prefs.dir}' fileset dir=${descriptor.dir.app}/${app-prefs.name} includes=**/ /copy /then /if if available file='${containers.dir}/${app-prefs.name}' type=dir/ then copy todir='${app-prefs.dir}' fileset dir=${containers.dir}/${app-prefs.name} includes=**/ /copy /then /if if available file='${app-prefs.name}' type=dir/ then copy todir='${app-prefs.dir}' fileset dir=${app-prefs.name} includes=**/ /copy /then /if /sequential /macrodef Today, I need to do this by calling antcall because I need to pass diferent parameters in different places. It will look much better that instead of: antcall target=prefs.app param name=app-prefs.name value=war-res/ param name=app-prefs.dir value=${war-res.app}/ /antcall I can just say: preferential-copy app-prefs.name=war-res app-prefs.dir=${war-res.app}/ You can see that using scriptdef to do this job is absolute madness. Since all you need is to put toguether some tasks. Substitution is the least interfearing behavior. I hear you and to a certain degree I agree with you. Actually I haven't really made up my mind myself yet - no vote from me so far. But if atributes modify properties, then there is no way for me to stop them for happening. In which situation would atributes modify properties have negative effects on what you are planing to do with macrodef? Do you have an enlightening example? macrodef name=myMacro attribute name=debug/ element name=code/ sequential if istrue value=${debug} then echomyMacro: Entering my macro/echo code/ echomyMacro: Entering my macro/echo /then else code/ /else /if /sequential /macrodef So here we have this simple macro that adds some debug information. So I use it like: myMacro debug=true code my.javac srcdir=test/src .../ /code /myMacro Still, very naïve code. Until you see that the definition of my.java is: presetdef name=my.javac javac srcdir=src destdir=classes deprecation=${deprecation} debug=${debug}/ /presetdef No here the intention of the code writer was to control javac using the debug property. But just
RE: macrodef - do attributes as properties or substitutions
I think I need to justify some more what do I think the way I do about macrodef. I know the vote is already going, but I really want for people to understand my position. To me macrodefs are for writing all those tasks that I am too lazy, or they are too simple for me to need to go and write and maintain some Java code. It is not to replace antcall/ but as a side efect, it will replace all those little antcalls we wrote because we didn't want to write java. With that in mind, I would want macrodef to resemble a Java task and not to resemble ant(call). And if it resemples a java task, then attributes should resemble java variables in my code. That is, its values should not affect the values of properties (which is what local does). If I want a task to affect other tasks then I can always call property or local as part of the macro. But if atributes modify properties, then there is no way for me to stop them for happening. Substitution is the least interfearing behavior. So, that is why I think the way I do. Comments? changes of votes? :-) Jose Alberto -Original Message- From: Stefan Bodewig [mailto:[EMAIL PROTECTED] Sent: 11 November 2003 12:23 To: [EMAIL PROTECTED] Subject: [VOTE] macrodef - do attributes as properties or substitutions Hi, I don't think that another discussion thread will lead us anywhere. Instead of trying to summarize what has been discussed, let me point to the archives (I hope the list is complete): http://marc.theaimsgroup.com/?t=10608526902r=1w=2 http://marc.theaimsgroup.com/?t=10663364313r=1w=2 http://marc.theaimsgroup.com/?t=10667505815r=1w=2 http://marc.theaimsgroup.com/?t=10663917564r=1w=2 http://marc.theaimsgroup.com/?t=10667294715r=1w=2 http://marc.theaimsgroup.com/?t=10672090301r=1w=2 http://marc.theaimsgroup.com/?t=10676180933r=1w=2 I'd like to keep this particular vote focussed on property versus textual substitution. I am aware that the vote won't be complete after that as we'll still have issues to decide upon (scope+extent or notation, depending on this vote's outcome), but let's get this one here straight first. Actually, I'm not 100% sure about the rules we have to apply since we've already shipped betas with the code, so strictly speaking a decision we are considering a code change which would require (lazy) consensus of the committers as opposed to a new idea that would require a majority only. Let's see where we get from here and whether we'll have to actually decide that at all 8-) Stefan OK, how do we want to implement macrodef attributes: [ ] as textual substitution [ ] as real Ant properties - 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: macrodef - do attributes as properties or substitutions
From: Steve Cohen [mailto:[EMAIL PROTECTED] Wouldn't you say, though, Jose, that macrodef does replace those uses of antcall for which antcall had too big a footprint for the job? Oh, but of course. I do plan to use macrodef to replace things that I did with antcall before. But the reason they were done with antcall before, is that it was more convinient than writing the equivalent script or java code; they did not need to evaluate multiple targets or other complex stuff. For things more complex, antcall is still the way to go. Why? Because it provides a new execution context, in which I can deside whether properties are inherited or not, and it provides isolation so that the parent context is not directly manipulated by the child. macrodef using local would be a cluge in the middle, half here half there, which I think is wrong. Either is a macro definition (as the term is defined in computer science form the days of assembler) it should be called something else and have a real execution context. BTW, how this things will affect the other tasks derived from macrodef like presetdef? Jose Alberto -Original Message- From: Jose Alberto Fernandez [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 11, 2003 11:19 AM To: Ant Developers List Subject: RE: macrodef - do attributes as properties or substitutions I think I need to justify some more what do I think the way I do about macrodef. I know the vote is already going, but I really want for people to understand my position. To me macrodefs are for writing all those tasks that I am too lazy, or they are too simple for me to need to go and write and maintain some Java code. It is not to replace antcall/ but as a side efect, it will replace all those little antcalls we wrote because we didn't want to write java. With that in mind, I would want macrodef to resemble a Java task and not to resemble ant(call). And if it resemples a java task, then attributes should resemble java variables in my code. That is, its values should not affect the values of properties (which is what local does). If I want a task to affect other tasks then I can always call property or local as part of the macro. But if atributes modify properties, then there is no way for me to stop them for happening. Substitution is the least interfearing behavior. So, that is why I think the way I do. Comments? changes of votes? :-) Jose Alberto -Original Message- From: Stefan Bodewig [mailto:[EMAIL PROTECTED] Sent: 11 November 2003 12:23 To: [EMAIL PROTECTED] Subject: [VOTE] macrodef - do attributes as properties or substitutions Hi, I don't think that another discussion thread will lead us anywhere. Instead of trying to summarize what has been discussed, let me point to the archives (I hope the list is complete): http://marc.theaimsgroup.com/?t=10608526902r=1w=2 http://marc.theaimsgroup.com/?t=10663364313r=1w=2 http://marc.theaimsgroup.com/?t=10667505815r=1w=2 http://marc.theaimsgroup.com/?t=10663917564r=1w=2 http://marc.theaimsgroup.com/?t=10667294715r=1w=2 http://marc.theaimsgroup.com/?t=10672090301r=1w=2 http://marc.theaimsgroup.com/?t=10676180933r=1w=2 I'd like to keep this particular vote focussed on property versus textual substitution. I am aware that the vote won't be complete after that as we'll still have issues to decide upon (scope+extent or notation, depending on this vote's outcome), but let's get this one here straight first. Actually, I'm not 100% sure about the rules we have to apply since we've already shipped betas with the code, so strictly speaking a decision we are considering a code change which would require (lazy) consensus of the committers as opposed to a new idea that would require a majority only. Let's see where we get from here and whether we'll have to actually decide that at all 8-) Stefan OK, how do we want to implement macrodef attributes: [ ] as textual substitution [ ] as real Ant properties - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]