Hi all,
I have updated the local properties patch to
make use of the new PropertyHelper delegate infrastructure.
(see: http://issues.apache.org/bugzilla/show_bug.cgi?id=23942)
The idea behind local properties is to provide
isolation of properties within element blocks - like
macrodefs and sequential. The main use case of
course is for macrodefs.
With current macrodefs, there is a number of work-arounds
to handle the fact that ant properties are global and unmodifiable
(i.e. write once).
1) invent a new name based on attribute values
2) use ac:var unset="yes"
for example:
<macrodef name="remove-log4js">
<attribute name="destdir">
<element name="jars" implicit="yes"/>
<sequential>
<mkdir dir="@{destdir}"/>
<ac:for parm="jar">
<jars/>
<sequential>
<basename property="[EMAIL PROTECTED]" file="@{jar}"/>
<remove-log4j srcfile="@{jar}"
dstfile="@{destdir}/[EMAIL PROTECTED]"/>
</sequential>
</>
</>
</>
or: (2):
<ac:var name="jar-base-name" unset="yes"/>
<basename property="jar-base-name" file="@{jar}"/>
<remove-log4j srcfile="@{jar}"
dstfile="@{destdir}/no-log4j-${jar-base-name}"/>
Both of these methods pollute the global property namespace with properties
that are just mean to be used internally within the macrodef instance.
The <local> property patch makes a property that is only alive within
a particular scope.
So the above code becomes:
<local name="jar-base-name"/>
<basename property="jar-base-name" file="@{jar}"/>
<remove-log4j srcfile="@{jar}"
dstfile="@{destdir}/no-log4j-${jar-base-name}"/>
and on exit from the macro, there would be no "jar-base-name" property.
And it there was a global "jar-base-name" property, it would *not* be
overwritten,
or used within the macrodef.
The <local> patch uses the following elements for block scopeing -
<target> and <sequential>.
(I think that this could be restricted to just <sequential>).
Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
