ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Davy Toch <Davy.T...@belgacom.net>
Subject Re: Scoped variables in macrodefs using entity includes.
Date Tue, 13 Sep 2005 20:45:47 GMT
Improved version (using ant-contrib). I suppose we'll have to wait for 
ANT 1.7 in order to have a 100% solution for scoped variables.

build.xml :

<?xml version='1.0'?>
<!DOCTYPE project [
 <!ENTITY project-uid "be.steria.ant.addon.0.3.base">
 <!ENTITY test-uid "&project-uid;test">
]>
<project basedir="." name="&project-uid;" default="test">

 <import file="macrodef.xml"/>

 <target name="test">
   <property name="&test-uid;.test" value="zzz"/>
   <echo>&test-uid;.test : ${&test-uid;.test}</echo>
   <macrodef1 test="${&test-uid;.test}"/>
   <macrodef1 test="1"/>
   <macrodef1 test="2"/>
   <macrodef1 test="3"/>
   <macrodef1 test="4"/>
   <macrodef1 test="5"/>
   <macrodef2 test="6"/>
   <macrodef2 test="7"/>
   <macrodef2 test="8"/>
   <macrodef2 test="9"/>
   <macrodef2 test="10"/>
 </target>

</project>

macrodef.xml:

<?xml version='1.0'?>
<!DOCTYPE project [
 <!ENTITY project-uid "be.steria.ant.addon.0.3.test">
 <!ENTITY macrodef1-uid "&project-uid;.macrodef1">
 <!ENTITY macrodef2-uid "&project-uid;.macrodef2">
]>
<project basedir="." name="&project-uid;"
xmlns:c="antlib:net.sf.antcontrib">

 <macrodef name="macrodef1">
   <attribute name="test"/>
   <sequential>
     <c:var name="&macrodef1-uid;.test" value="@{test}"/>
     <echo>&macrodef1-uid;.test : ${&macrodef1-uid;.test}</echo>
   </sequential>
 </macrodef>

 <macrodef name="macrodef2">
   <attribute name="test"/>
   <sequential>
     <c:var name="&macrodef2-uid;.test" value="@{test}"/>
     <echo>&macrodef2-uid;.test : ${&macrodef2-uid;.test}</echo>
   </sequential>
 </macrodef>

</project>

>
>
>> I don't see how this really helps, I'm sorry ;-)
>>
>> The problem is when you invoke *several times* a macrodef that uses
>> <property> internally. You would need to use a different prefix (that
>> what your entity is equivalent to) for the different runs of the same
>> macro to use different property names.
>>
>> Which is why the 'canonical' work-around is to base the name of the
>> <property>s used on some likely-to-be-unique param of the macro
>> itself, and do ${@{param}suffix} to reference the 'internal' property.
>>
>> One could also of course have the macro require an extra param to be
>> used as the uniq key or prefix to be used by internal properties, but
>> that's pushing on a client of the macro something she shouldn't be
>> aware of. --DD
>>  
>>
>
>

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


Mime
View raw message