ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Benson <gudnabr...@yahoo.com>
Subject Re: Local Properties
Date Wed, 22 Aug 2007 16:22:41 GMT
Apologies for the top post but yours was rather long. 
;)  I like the approach patch; I have applied it but
don't have time to exercise it ATM.  The only issue I
see is that I am apparently too stupid to understand
how copying the current stack for new threads works. 
What I see:

<parallel> kicks off a given TaskRunnable t in its own
thread.
t.run() gets the LocalProperties for the current
project and calls copy().
LP.copy() copies/replaces its own current LPStack.

but the current LPStack is the ThreadLocal value, so
getting that value under the authority of the
TaskRunnable thread should yield a new LPStack,
generated by LP.initialValue(), no?  Isn't the
objective here to copy the new stack from the parent
stack?  Shouldn't the copy then take place under the
originating thread?  What am I missing here?

-Matt

--- Peter Reilly <peter.kitt.reilly@gmail.com> wrote:

> 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="jarfile-@{jar}" file="@{jar}"/>
>                      <remove-log4j srcfile="@{jar}"
> dstfile="@{destdir}/no-log4j-${jarfile-@{jar}}"/>
>                </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:
> dev-unsubscribe@ant.apache.org
> For additional commands, e-mail:
> dev-help@ant.apache.org
> 
> 



       
____________________________________________________________________________________
Choose the right car based on your needs.  Check out Yahoo! Autos new Car Finder tool.
http://autos.yahoo.com/carfinder/

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


Mime
View raw message