ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Inger, Matthew" <>
Subject RE: Target or macrodef?
Date Wed, 25 Aug 2004 20:41:22 GMT
As a followup to my comment about local variables in macrodefs, turns out,
it would only take a few lines of code over 3 classes to make it happen:
	1.  PropertyHelper - add ability to remove a property
	2.  MacroDef - allow a <local> subelement
	3.  MacroInstance - cleanup local variables after execution

<macrodef ...>
  <local name="abc" />
    <property name="abc" value="xyz" />

With the <local> element in there, it's telling the macrodef that
the property "abc" is local, and should be removed when execution is
finished.  I had tried to be able to replace <property> with <local>, so
that you didn't have to seperate the declaration of it being local and the
definition of it's value.  However, it looks too complicated for someone
who's not that knowledgable about the inner workings of the ANT code to do
very easily.

-----Original Message-----
From: Jeffrey Bacon []
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
Creative Developer

Jacob Kjome wrote:
> Well put!  However...
>>There is one drawback to this approach and that is that the target cannot
>>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
>>change their value.
> This is why it is, technically, a "hack".  Keep in mind, I use the term in
> nicest way possible.  That this works perfectly fine in 99% of the cases
> that I find it very useful, understandable, and maintainable, I think it
> perfectly legitimate.  But the fact that there seems to be a need for
> throw-away, properties means that Ant should, arguably, provide a
construct for
> this which serves this purpose exactly without side effects like those
> 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
> property name.  You'd have to set it up where any one attribute value
> occur more than once, but the chances of the combination happening more
> 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 <>:
>>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
>>a temporary property. I am not even sure I could do this with <antcall>
>>I would not want the overhead anyway.
>>The background on this snippet is that I need a list of files in a file
>>use by a merge program. Here I make a temp prop ({rbfile}) to
>>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
>>sure the file was actually created before I put it in the temp file. (It
>>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
>>something it was not designed to do but it works. I don't consider this
>>any more difficult to maintain than any other code I have to work with.
>>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
>>code is not that difficult.
>>There is one drawback to this approach and that is that the target cannot
>>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
>>change their value.
>>Local properties may be a benefit in this and some other cases but I am
>>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="{rbfile}"/>
>>    <available file="${PRODUCT}/${{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}/${{rbfile}}.str"/>
>>      </then>
>>    </if>
>>  </sequential>
>><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
>> or
>>-----Original Message-----
>>From: Jacob Kjome []
>>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:
>>>>>this would be great !
>>>>>recently, i had exactly that problem (setting a "temp" property in
>>>>><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...
>>>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
>>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
>>might be nice, but it won't bother me if it never makes it into Ant as the
>>"hack" is all I need.
>>>To unsubscribe, e-mail: For additional
>>>commands, e-mail:
>>To unsubscribe, e-mail: For additional
>>commands, e-mail:
>>To unsubscribe, e-mail:
>>For additional commands, e-mail:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message