Gotcha--I missed that the first time around. If you want to restrict the scope of a property set by a task, you essentially reserve that property in the local context, then invoke the task. This should work although I like my way better... ;)
I think it is okay to force the user to explicitly send local values for ant and antcall, but that's just me... I wouldn't think it would be too hard to do it the other way either, but what if you need to send the global version? 0.02 -Matt --- peter reilly <[EMAIL PROTECTED]> wrote: > 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: > === 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]
