 | | | Target or macrodef? | Target or macrodef? 2004-08-25 - By Bill Rich
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)
|
|
|
