ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Reilly <>
Subject Re: ant-contrib <for> and property immutability
Date Tue, 27 Jan 2004 09:22:16 GMT
Stirling, Scott wrote:

>I am writing to share my workaround for a gotcha I encountered with the latest ant-contrib
<for> tak (version 0.6) and some standard Ant tasks.  And if anyone has a better workaround/solutions,
please let me know.
>Consider a <for> loop like this, which does the following:
>- loops over a fileset in a path
>- derives the basename of each non-ejb jar in the fileset
>- echoes the base jar name + a space char to a file that is later read-in to create the
ClassPath entry for the EJB jars manifest (not shown)
><for param="nonejbjar">
>  <path>
>    <fileset dir="${ear.root}">
>      <include name="*.jar"/>
>      <exclude name="*-ejb*.jar"/>
>    </fileset>
>  </path>
>  <sequential>
>    <!-- note the tricky ($) property 
>     and (@) property use to uniquify the
>     basename property each time through the 
>     loop -->
>    <basename property="{nonejbjar}"
>              file="@{nonejbjar}"/>
>    <echo append="true" 
>          file="${assembler.cache}/manifest.generated"
>          message="${{nonejbjar}} "/>
>  </sequential>
>The comment points out the tricky thing I had to learn today, which is that <for>
can have interesting side-effects when used with tasks that create properties.  Which essentially
makes certain tasks unusable with the <for> task, or requires a tricky workaround.
>There's the trick I used for the <basename> task: each time through the loop, the
current value of @{nonejbjar} (from the fileset) is appended to the ${} property
name, which tells basename to create a uniquely named property each time through the loop.
 Here the property name is only used in the loop to dereference the value in the <echo>
task, so it doesn't matter what the name really is.  Note the nested ${{nonejbjar}}
syntax to dereference the Ant property and the macrodef attribute.

>One alternative I considered was writing a regular expression using ant-contrib's <propertyregex>
instead of using the <basename> task.  This task allows for overriding the property
name if it is already set.  But then I found this was easier and a more general solution.
I use <propertyregex> to emulate basename plus removing extension as 

          <ac:propertyregex override="yes"
                            property="program"  input="@{file}"
                            regexp=".*/([^\.]*)\.cpp" replace="\1"/>

(works for unix with  / as the dir separator).

>An "override" attribute for some property-creating tasks like <basename> would be
pretty handy, I think.
A general purpose local property as described by
would work as well.


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

View raw message