You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@ant.apache.org by "Stirling, Scott" <sc...@workscape.com> on 2004/01/26 22:00:20 UTC
ant-contrib and property immutability
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="non.ejb.jar.name@{nonejbjar}"
file="@{nonejbjar}"/>
<echo append="true"
file="${assembler.cache}/manifest.generated"
message="${non.ejb.jar.name@{nonejbjar}} "/>
</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 ${non.ejb.jar.name@{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.
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: user-unsubscribe@ant.apache.org
For additional commands, e-mail: user-help@ant.apache.org
ANT taskdef caused IDE problems
Posted by Matthew Oatham <ma...@hotmail.com>.
Has anyone tried to use the ANT task to pre compile web apps as described at
http://jakarta.apache.org/tomcat/tomcat-4.1-doc/jasper-howto.html#Web%20Application%20Compilation
I have tried this and it all works well but when I run the task from within
my IDE Sun ONE Studio I get an IDE task left hanging around - when I close
the IDE it says "Waiting for IDE task to finish" Has anyone else seen this
problem? Could it be because the taskdef for the jasper2 taks is loading
many JAR files? Any ideas?
Regards,
Matt
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@ant.apache.org
For additional commands, e-mail: user-help@ant.apache.org
Re: ant-contrib and property immutability
Posted by Matt Benson <gu...@yahoo.com>.
--- Peter Reilly <pe...@corvil.com> wrote:
> A general purpose local property as described by
>
http://issues.apache.org/bugzilla/show_bug.cgi?id=23942
> would work as well.
So go vote for it!
-Matt
__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free web site building tool. Try it!
http://webhosting.yahoo.com/ps/sb/
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@ant.apache.org
For additional commands, e-mail: user-help@ant.apache.org
Re: ant-contrib and property immutability
Posted by Peter Reilly <pe...@corvil.com>.
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="non.ejb.jar.name@{nonejbjar}"
> file="@{nonejbjar}"/>
> <echo append="true"
> file="${assembler.cache}/manifest.generated"
> message="${non.ejb.jar.name@{nonejbjar}} "/>
> </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 ${non.ejb.jar.name@{nonejbjar}} syntax to dereference the Ant property and the macrodef attribute.
>
>
Neat.
>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
follows:
<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
http://issues.apache.org/bugzilla/show_bug.cgi?id=23942
would work as well.
Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@ant.apache.org
For additional commands, e-mail: user-help@ant.apache.org
Re: ant-contrib and property immutability
Posted by Dale Anson <da...@germane-software.com>.
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="non.ejb.jar.name@{nonejbjar}"
> file="@{nonejbjar}"/>
> <echo append="true"
> file="${assembler.cache}/manifest.generated"
> message="${non.ejb.jar.name@{nonejbjar}} "/>
> </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 ${non.ejb.jar.name@{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.
>
> 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: 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