Target or macrodef? 2004-08-25 - By Dick, Brian E.
Variables and your proposal below are not a solution for tasks that set
properties, e.g. exec, loadfile, etc. You need to surround the macro
body with scoping tags or maybe just add an option to the sequential
tag. Something like
<macrodef name="mymacro">
...
<sequential>
<localscope>
...
</localscope>
</sequential>
</macrodef>
Or
<macrodef name="mymacro">
...
<sequential localscope="true">
...
</sequential>
</macrodef>
-----Original Message-----
From: Inger, Matthew [mailto:Inger@(protected)]
Sent: Wednesday, August 25, 2004 3:01 PM
To: 'Jeffrey Bacon'; Ant Users List
Subject: RE: Target or macrodef?
I was trying to stay away from Ant Contrib in this discussion
(even though I'm the project admin on it). The bottom line is
that they way macros are implemented makes declaring properties
inside of the macrodef very difficult, as it's hard to re-use the
macros and/or the calling targets.
It's something that ANT itself should handle. Perhaps either the
stackable approach as i mentioned, or maybe another task like:
<local name="local.property" value="..." />
Any "local" variables get cleaned when the macro finishes running.
This should be a very easy approach to implement.
-----Original Message-----
From: Jeffrey Bacon [mailto:jbacon@(protected)]
Sent: Wednesday, August 25, 2004 12:40 PM
To: Ant Users List
Subject: Re: Target or macrodef?
you all know you can use the Ant Contrib libraries and get 'var' which
is mutable properties eh? Doesn't that kinda make temp properties a
moot point? I guess you are dependent on a library then.
--
Jeffrey Bacon
jbacon@(protected)
Creative Developer
http://www.magmic.com
Jacob Kjome wrote:
> Well put! However...
>
>
>>There is one drawback to this approach and that is that the target
cannot
be
>>used again in the same process instance. If it is used again the
temporary
>>properties may cause a conflict because of their immutability if you
try
to
>>change their value.
>
>
> This is why it is, technically, a "hack". Keep in mind, I use the
term in
the
> nicest way possible. That this works perfectly fine in 99% of the
cases
and
> that I find it very useful, understandable, and maintainable, I think
it
is
> perfectly legitimate. But the fact that there seems to be a need for
temporary,
> throw-away, properties means that Ant should, arguably, provide a
construct for
> this which serves this purpose exactly without side effects like those
described
> by your own comment.
>
> BTW, you can usually cut down on the possibility of dynamic property
name
> duplicates by using two or more macrodef attribute values to create
the
dynamic
> property name. You'd have to set it up where any one attribute value
might
> occur more than once, but the chances of the combination happening
more
than
> once is much less. You may not always have this opportunity, but
depending on
> the values coming in, you may be able to use them to your advantage.
>
> Jake
>
>
> Quoting Bill Rich <billrich@(protected)>:
>
>
>>I guess I must disagree with both of you to some degree. In this
snippet
>>from an Ant file that I use for process control (not a build process)
I
need
>>a temporary property. I am not even sure I could do this with
<antcall>
but
>>I would not want the overhead anyway.
>>
>>The background on this snippet is that I need a list of files in a
file
for
>>use by a merge program. Here I make a temp prop (file.in.@{rbfile}) to
hold
>>the file name that I get from a list that has been loaded earlier in
the
>>process. I also use a temp prop (file.exists.@{rbfile}.str) to test to
make
>>sure the file was actually created before I put it in the temp file.
(It
is
>>the nature of the process that some of these files may not be created
and
>>the merge program horks if the file is not available. A better
solution to
>>checking availability would be to fix the merge program so it
tolerates
>>missing files.)
>>
>>I disagree that this is a hack. It is nothing more than coding to the
any
>>language spec. Property immutability is a fact in ant and I accept
that (I
>>even agree with it). This is a case where I need to have a bunch of
>>properties because of the type of processing I am doing. I am using
ant
for
>>something it was not designed to do but it works. I don't consider
this
code
>>any more difficult to maintain than any other code I have to work
with.
Most
>>of the code I work with is not mine and sometimes has been coded to
many
>>different standards. That code is difficult to read and understand.
This
ant
>>code is not that difficult.
>>
>>There is one drawback to this approach and that is that the target
cannot
be
>>used again in the same process instance. If it is used again the
temporary
>>properties may cause a conflict because of their immutability if you
try
to
>>change their value.
>>
>>Local properties may be a benefit in this and some other cases but I
am
not
>>going to worry if they never get implemented. This works just fine.
>>
>><... snip ...>
>><tempfile property="temp.rbstr.file" suffix=".txt"/>
>><record name="${temp.rbstr.file}" emacsmode="true" action="start"/>
>><for list="${rbfilelist}" delimiter=";" param="rbfile">
>> <sequential>
>> <getsrcname listitem="@{rbfile}" property="file.in.@{rbfile}"/>
>> <available file="${PRODUCT}/${file.in.@{rbfile}}.str"
>>property="file.exists.@{rbfile}.str" value="avail"/>
>> <if>
>> <equals arg1="${file.exists.@{rbfile}.str}" arg2="avail"/>
>> <then>
>> <property name="rbstrFilesAvailable" value="true"/>
>> <echo message="${PRODUCT}/${file.in.@{rbfile}}.str"/>
>> </then>
>> </if>
>> </sequential>
>></for>
>><record name="${temp.rbstr.file}" action="stop"/>
>><... snip ...>
>>
>>Thanks. Bill
>>
>>Bill Rich
>>Wilandra Consulting LLC
>>1325 Addiewell Place
>>San Jose, CA 95120-3905
>>phone: +1 408 268-2452
>>mobile: +1 408 410-9713
>>Santa Cruz: +1 831 464-9007
>>fax: +1 413 669-9716
>>billrich@(protected) or billrich@(protected)
>>http://www.wilandra.com
>>
>>-----Original Message-----
>>From: Jacob Kjome [mailto:hoju@(protected)]
>>Sent: Wednesday, August 25, 2004 6:55 AM
>>To: Ant Users List
>>Subject: Re: Target or macrodef?
>>
>>At 08:48 AM 8/25/2004 +0200, you wrote:
>>
>>>>>hi,
>>>>>this would be great !
>>>>>
>>>>>recently, i had exactly that problem (setting a "temp" property in
>>>>>a
>>>>><macrodef/>) ... i had to use <antcall/> as work-around :(
>>>>>
>>>>
>>>>Well, <antcall> is just totally unnecessary. Just use the value of
>>>>the macrodef attributes as a property. Obviously it becomes a
>>>>property that will live throughout the app, but it is usually so
>>>>unique that that you'd never define or generate another property by
>>>>the same name. If the value won't be unique, you can chain multiple
>>>>macrodef attribute values together to make a truly unique property.
>>>>For more information, see...
>>>>
>>>>http://ant.apache.org/faq.html#propertyvalue-as-name-for-property
>>>
>>>i disagree - i guess there are of course reasons for using <antcall/>
>>>and i guess my example above is one of them.
>>>
>>>while ur "solution" or better called "work-around" may work too i
>>>would not use it cause THIS is an ugly hack - thats the way
>>>unmaintainable code is produced! what u r talking about is
"generating"
>>>property names and this does definitively makes the code harder to
read
>>>... at least IMHO ... what does a generated property name tell about
>>>its use or the coders intention ? nothing!
>>>i guess the best and obious solution would be to allow some kind of
>>>variable scoping in ant.
>>
>>I see your point and I already referred to it as a "hack", but I
disagree
>>that it is unmaintainable. Since the property is meant to be used
>>temporarily, the confusion will only be in one place; the macrodef
itself.
>>I would suggest simply writing a comment saying what exactly is being
done.
>>Most macrodefs aren't tremendously large so a little documentation
should
>>suffice to ease or resolve any confusion that might otherwise occur.
The
>>bloat and messiness of <antcall> far outweighs any disadvantages of
the
>>current "hack" available in macrodef. Like I said before, a local
property
>>might be nice, but it won't bother me if it never makes it into Ant as
the
>>"hack" is all I need.
>>
>>Jake
>>
>>
>>
>>>thx
>>>regards,
>>>seb
>>>
>>><snip/>
>>>
>>>---------------------------------------------------------------------
>>>To unsubscribe, e-mail: user-unsubscribe@(protected) For
additional
>>>commands, e-mail: user-help@(protected)
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: user-unsubscribe@(protected) For additional
>>commands, e-mail: user-help@(protected)
>>
>>
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: user-unsubscribe@(protected)
>>For additional commands, e-mail: user-help@(protected)
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@(protected)
> For additional commands, e-mail: user-help@(protected)
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@(protected)
For additional commands, e-mail: user-help@(protected)
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@(protected)
For additional commands, e-mail: user-help@(protected)
|
|
