I have made a version that inherits local properties for ant/antcall et al (if inheritall is true).
Will post tomorrow. Peter On Monday 20 October 2003 17:44, Jose Alberto Fernandez wrote: > Peter, > > I just made a browse to the changes you posted and I can see > why you are concern with ant/antcall. I see you did quite large > additions to core in order to implement this (using ThreadLocals). > > I wonder if we can explore a more simpler implementation that is > less onerous than the one you have. I would think that adding > that making <parallel> pay for the cost of treating the computations > separately will make things simpler and make more posible to > do the right thing for ant/antcall. > > BTW, we are not talking ONLY about ant/antcall. We are talking > about them and about ALL the user implemented versions of <foreach> > <forall>, etc, etc that are around because we never provide one > in core. We cannot just break their them. > > Do you see any reasonable way in which <parallel> could create > separate copies of its properties for each execution thread? > I will try to see if I getthe time to propose actual code. > But I have been kind of burden ere at work. > > Jose Alberto > > > -----Original Message----- > > From: peter reilly [mailto:[EMAIL PROTECTED] > > Sent: 20 October 2003 16:54 > > To: Ant Developers List > > Subject: Re: Macrodef and parallel in a recursive situation > > > > > > This is basicly what the local implementation > > does. > > > > The only problem is for ant/antcall, a new project > > is created and the local properties would need > > to be copied to this, keeping in mind all the > > rules about user/normal/inherited and nested param > > elements. > > > > Peter > > > > On Monday 20 October 2003 16:16, Matt Benson wrote: > > > Jose makes a good point about tasks that set > > > properties. Without having delved into the > > > PropertyHelper* classes, could local properties be > > > handled some other way? What about a Scope > > > TaskContainer subclass that would push an element onto > > > a stack. Then any property queries would descend into > > > the stack... then a task that set a property could > > > have that property restricted by nesting it in a set > > > of <scope> tags... > > > > > > -Matt > > > > > > > > > --- Jose Alberto Fernandez <[EMAIL PROTECTED]> > > > > > > wrote: > > > > > From: Christopher Lenz [mailto:[EMAIL PROTECTED] > > > > > > > > > > Hi Peter, > > > > > > > > > > this looks really cool, but I'd suggest adding an > > > > > > > > attribute like > > > > > > > > > scope="local|global" to the <property> task > > > > > > > > instead of adding > > > > > > > > > a completely > > > > > new task. > > > > > > > > I disagree here. The issue is not <property> by > > > > itself. This local > > > > properties need to work with every <task> that may > > > > set a property: > > > > <condition>, <available>, <uptodate>, <property>, > > > > and a million more > > > > obscure ones. The main use for <local> is when it is > > > > called without > > > > the value attribute, because in that case this other > > > > tasks will > > > > set the local property and not the global one. > > > > > > > > Jose Alberto > > > > > > > > > -chris > > > > > > > > > > peter reilly wrote: > > > > > > I have written the code to support local > > > > > > > > properties. > > > > > > > > > > While I was doing this, I realized that the > > > > > > > > attributes > > > > > > > > > > of a macrodef could/should be local properties > > > > > > > > as well, > > > > > > > > > removing some > > > > > > > > > > > of the issues seen last week (use of attribute > > > > > > > > in a bsf script and > > > > > > > > > > support of parallel/recursive). > > > > > > > > > > > > The following shows it in using a new task > > > > > > > > called local. > > > > > > > > > > <project name="local"> > > > > > > <property name="prop1" value="a global > > > > > > > > value"/> > > > > > > > > > > <target name="test1"> > > > > > > <local name="prop1" value="a local value"/> > > > > > > <echo>prop1 is "${prop1}"</echo> > > > > > > </target> > > > > > > <target name="test2" depends="test1"> > > > > > > <echo>prop1 is "${prop1}"</echo> > > > > > > </target> > > > > > > </project> > > > > > > > > > > > > This ant test2 generates the following: > > > > > > > > > > > > test1: > > > > > > prop1 is "a local value" > > > > > > > > > > > > test2: > > > > > > prop1 is "a global value" > > > > > > > > > > > > Each taskcontainer sets up a new local scope: > > > > > > > > > > > > <target name="sequential"> > > > > > > <local name="prop2" value="in target"/> > > > > > > <sequential> > > > > > > <local name="prop2" value="in > > > > > > > > sequential"/> > > > > > > > > > > <echo>prop2 is "${prop2}"</echo> > > > > > > </sequential> > > > > > > <echo>prop2 is "${prop2}"</echo> > > > > > > </target> > > > > > > > > > > > > will generate the following: > > > > > > sequential: > > > > > > prop2 is "in sequential" > > > > > > prop2 is "in target" > > > > > > > > > > > > The value part of <local> is optional, and the > > > > > > > > local > > > > > > > > > property may be > > > > > > > > > > > set by a subsequent <property>, <property> will > > > > > > > > only set it if the > > > > > > > > > > value is not set. > > > > > > > > > > > > <target name="notset"> > > > > > > <local name="prop3"/> > > > > > > <echo>prop3 is "${prop3}"</echo> > > > > > > <property name="prop3" value="is set"/> > > > > > > <property name="prop3" value="is set > > > > > > > > again"/> > > > > > > > > > > <echo>prop3 is "${prop3}"</echo> > > > > > > </target> > > > > > > > > > > > > will generate the following: > > > > > > notset: > > > > > > prop3 is "${prop3}" > > > > > > prop3 is "is set" > > > > > > > > > > > > prop3 is still a local variable and will not be > > > > > > > > seen outside the > > > > > > > > > > target. > > > > > > > > > > > > The local properties are thread local so the > > > > > > > > following > > > > > > > > > works as expected: > > > > > > <target name="parallel"> > > > > > > <local name="prop4"/> > > > > > > <parallel> > > > > > > <sequential> > > > > > > <property name="prop4" value="thread1"/> > > > > > > <echo>t1: prop4 is "${prop4}"</echo> > > > > > > </sequential> > > > > > > <sequential> > > > > > > <property name="prop4" value="thread2"/> > > > > > > <echo>t2: prop4 is "${prop4}"</echo> > > > > > > </sequential> > > > > > > <sequential> > > > > > > <property name="prop4" value="thread3"/> > > > > > > <echo>t3: prop4 is "${prop4}"</echo> > > > > > > </sequential> > > > > > > </parallel> > > > > > > </target> > > > > > > > > > > > > parallel: > > > > > > t2: prop4 is "thread2" > > > > > > t1: prop4 is "thread1" > > > > > > t3: prop4 is "thread3" > > > > > > > > > > > > Use with macrodef. > > > > > > ----------------- > > > > > > > > > > > > Attributes may now be implemented as local > > > > > > > > properties, which means > > > > > > > > > > that they will be seen as normal properties by > > > > > > > > ant tasks - > > > > > > > > > including > > > > > > > > > > > script. > > > > > > > > > > > > <target name="macro"> > > > > > > <macrodef name="callscript"> > > > > > > <attribute name="x"/> > > > > > > <sequential> > > > > > > <script language="beanshell"> > > > > > > System.out.println("x is '" + > > > > > > > > > > project.getProperty("x") + "'"); > > > > > > > > > > > </script> > > > > > > </sequential> > > > > > > </macrodef> > > > > > > > > > > > > <callscript x="this is x"/> > > > > > > </target> > > > > > > > > > > > > will generate: > > > > > > macro: > > > > > > x is 'this is x' > > > > > > > > > > > > Macrodef does not do the attribute substitutions > > > > > > > > so the following > > > > > > > > > > <target name="macro2"> > > > > > > <macrodef name="callscript"> > > > > > > <attribute name="x"/> > > > > > > <sequential> > > > > > > <script language="beanshell"> > > > > > > System.out.println("x is '${x}'"); > > > > > > </script> > > > > > > </sequential> > > > > > > </macrodef> > > > > > > > > > > > > <callscript x="this is x"/> > > > > > > </target> > > > > > > will generate: > > > > > > macro2: > > > > > > x is '${x}' > > > > > > as <script/> does not do property expansion. > > > > > > > > > > > > A variation of the recurive macrodef last week > > > > > > > > may be done by: > > > > > > <target name="recur"> > > > > > > <macrodef name="recur"> > > > > > > <attribute name="thread"/> > > > > > > <attribute name="current"/> > > > > > > <sequential> > > > > > > <antcontrib:if> > > > > > > <equals arg1="0" arg2="${current}"/> > > > > > > <then> > > > > > > <echo message="Thread: ${thread} > > > > > > > > done"/> > > > > > > > > > > </then> > > > > > > <else> > > > > > > <antcontrib:math > > > > > > datatype = "int" > > > > > > operand1 = "${current}" > > > > > > operation = "-" > > > > > > operand2 = "1" > > > > > > result = "current" > > > > > > /> > > > > > > <echo message = "T: ${thread}, C: > > > > > > > > ${current}" /> > > > > > > === message truncated === > > > > > > > > > __________________________________ > > > Do you Yahoo!? > > > The New Yahoo! Shopping - with improved product search > > > http://shopping.yahoo.com > > > > --------------------------------------------------------------------- > > > > > 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] > > --------------------------------------------------------------------- > 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]
