ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeffrey Bacon <>
Subject Re: Target or macrodef?
Date Wed, 25 Aug 2004 16:40:15 GMT
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 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 <>:
>>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 ({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="{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 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.
>>>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