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 Fri, 17 Oct 2003 19:18:50 GMT
I think that we may need a thread local variable to
handle parallel.

This would mean some deep messing with the Property handling.

Peter
On Friday 17 October 2003 17:57, Jose Alberto Fernandez wrote:
> > From: peter reilly [mailto:peter.reilly@corvil.com]
> >
> > I would rather have Jose's idea of a <local-property/>
> > task.
> >
> > This could be used outside of macrodef.
> >
> > The only problem is the implementation.
>
> Indeed, there is an easy implementation but will not solve the
> case of <parallel>, because the local definition would really be a
> temporary global one:
>
> public class LocalProperty extends Sequential {
>   private String property;
>   private String oldValue;
>
>   public setName(String i_property){property = i_property;}
>
>   public void execute() {
>     if (property == null) throw new BuildException("name attribute is
> mandatory");
>     try {
>       oldValue = getProject().getProperty(property);
>       getProject().setProperty(property, null); // This may need changes
> to core
>       super.execute();
>     }
>     finally {
>       // This is using the deprecated setProperty method
>       // that actually changes the properties even if set
>       getProject().setProperty(property, oldValue);
>     }
>   }
> }
>
> Here we just change the property value on the project frame, for the
> duration
> of the task. And put the old value back before we leave.
>
> The problem with this simple implementation is that all the parallel
> branches
> will see the change, which is exactly what we were trying to avoid. To
> do it
> right, we would need to create a new execution frame that would be use
> in the
> "super" call.
>
> But if we do that (which is like what <ant> or <antcall> do), what
> happens
> if the user defines properties other than the local-property inside the
> code?
> Somehow, we would need to find them and propagate them back to the frame
> above
> upon exit.
>
>   <local-property name="x">
>    <property name="y" value="myY"/>
>   <local-property>
>   <echo message="${y}"/>
>
> [echo] myY
>
> Doable, but not that easy anymore.
>
> What do you guys think?
>
> Jose Alberto
>
> > Peter
> >
> > On Friday 17 October 2003 17:02, Shatzer, Larry wrote:
> > > Maybe allow <attribute> have another <attribute> that
> >
> > allows it to be
> >
> > > undeclared with default or passed in, so we can set it inside the
> > > macrodef, such as "newcurrent".
> > >
> > > Example:
> > >
> > > <macrodef name="recursive">
> > >   <attribute name="until"/>
> > >   <attribute name="current"/>
> > >   <attribute name="method"/>
> > >   <attribute name="newcurrent" staticscope="true"/>
> > >   ...
> > > </macrodef>
> > >
> > > Then when you call "recursive" such as this: <recursive until="10"
> > > current="0" method="blah"/> it won't die that you did not pass
> > > "newcurrent".
> > >
> > > the "staticscope" attribute name could be something else, or
> > > scope="static" and a list of others that could be used.
> > >
> > > -- Larry
> > >
> > > > -----Original Message-----
> > > > From: peter reilly [mailto:peter.reilly@corvil.com]
> > > > Sent: Friday, October 17, 2003 12:43 AM
> > > > To: Ant Developers List
> > > > Subject: Re: Macrodef and parallel in a recursive situation
> > > >
> > > >
> > > > The parellel would cause grief.
> > > > The problem is not the attribute, I think
> > > > but the "newcurrent" global "variable".
> > > >
> > > > On using macrodef, I have noticed that
> > > > it would be really cool to have a static scopped
> > > > variable.
> > > >
> > > > Peter
> >
> > ---------------------------------------------------------------------
> >
> > > 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