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]
