Another option is to use ant-contrib's Variable task, which is a mutable
property. It is in the 0.6 ant-contrib release.
Dale
Stirling, Scott wrote:
> Hi,
>
> 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="[EMAIL PROTECTED]"
> file="@{nonejbjar}"/>
> <echo append="true"
> file="${assembler.cache}/manifest.generated"
> message="[EMAIL PROTECTED] "/>
> </sequential>
> </for>
>
> 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
> ${non.ejb.jar.name} 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 [EMAIL PROTECTED] 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.
>
> An "override" attribute for some property-creating tasks like <basename> would be
> pretty handy, I think.
>
> Regards,
> Scott Stirling
>
> ***********************************************************************
> This message is intended only for the use of the intended recipient and
> may contain information that is PRIVILEGED and/or CONFIDENTIAL. If you
> are not the intended recipient, you are hereby notified that any use,
> dissemination, disclosure or copying of this communication is strictly
> prohibited. If you have received this communication in error, please
> destroy all copies of this message and its attachments and notify us
> immediately.
> ***********************************************************************
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
