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 <[EMAIL PROTECTED]> 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="[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] > > ____________________________________________________________________________________ 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
