ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Reilly <peterrei...@apache.org>
Subject Re: Target or macrodef?
Date Wed, 25 Aug 2004 19:29:35 GMT
Inger, Matthew wrote:

>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.
>  
>
This is exactly the approach that the "local" patch takes.

The build snippet then becomes (after moving the available into the if 
condition):

<for	list="${rbfilelist}" delimiter=";" param="rbfile">
 <sequential>
   <local name="sourcefile"/>
   <getsrcname listitem="@{rbfile}" property="sourcefile"/>
   <if>
     <available file="${PRODUCT}/${sourcefile}.str"
     <then>
       <property name="rbstrFilesAvailable" value="true"/>
       <echo message="${PRODUCT}/${sourcefile}.str"/>
     </then>
   </if>
 </sequential>
</for>

In this case the local property gets created in the "unset" state, so 
<getsrcname/> can set
it.
The "sourcefile" property is local to the seqential block use - so a 
different local property
will be used each time thu the for loop.

Outside the for loop the "sourcefile" will not be set (unless there is 
already a "sourcefile" property).

Some of the issues with the patch were:

* what is the treatment of user properties - i.e. should local 
properties not be allowed to have the same
   name as user properties
* what is the scope of the local properties  - should there be a special 
block to delimit the
    scope of the variables.
* the implementation is a little complex (uses threadlocal stacks)- it 
perhaps could be less
* macrodef can be powerful without use of local varialbes - using the 
constructed names idea for
   semi-unique properties
* adding local properties makes the whole property mess^D rules more complex
* there is no local references

Peter

>-----Original Message-----
>From: Jeffrey Bacon [mailto:jbacon@magmic.com]
>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@magmic.com
>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@attglobal.net>:
>>
>>
>>    
>>
>>>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@wilandra.com or billrich@attglobal.net
>>>http://www.wilandra.com
>>>
>>>-----Original Message-----
>>>From: Jacob Kjome [mailto:hoju@visi.com]
>>>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@ant.apache.org For additional
>>>>commands, e-mail: user-help@ant.apache.org
>>>>        
>>>>
>>>---------------------------------------------------------------------
>>>To unsubscribe, e-mail: user-unsubscribe@ant.apache.org For additional
>>>commands, e-mail: user-help@ant.apache.org
>>>
>>>
>>>
>>>
>>>---------------------------------------------------------------------
>>>To unsubscribe, e-mail: user-unsubscribe@ant.apache.org
>>>For additional commands, e-mail: user-help@ant.apache.org
>>>      
>>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: user-unsubscribe@ant.apache.org
>>For additional commands, e-mail: user-help@ant.apache.org
>>
>>    
>>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: user-unsubscribe@ant.apache.org
>For additional commands, e-mail: user-help@ant.apache.org
>
>
>
>  
>


---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@ant.apache.org
For additional commands, e-mail: user-help@ant.apache.org


Mime
View raw message