ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From peter reilly <peter.rei...@corvil.com>
Subject Re: Macrodef and parallel in a recursive situation
Date Mon, 20 Oct 2003 17:28:16 GMT
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:peter.reilly@corvil.com]
> > 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 <jalberto@cellectivity.com>
> > >
> > > wrote:
> > > > > From: Christopher Lenz [mailto:cmlenz@gmx.de]
> > > > >
> > > > > 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: dev-unsubscribe@ant.apache.org
> > > For additional commands, e-mail: dev-help@ant.apache.org
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> > For additional commands, e-mail: dev-help@ant.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> For additional commands, e-mail: dev-help@ant.apache.org


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


Mime
View raw message