You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ant.apache.org by Peter Reilly <pe...@gmail.com> on 2007/08/22 13:23:31 UTC
Local Properties
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="jarfile-@{jar}" file="@{jar}"/>
<remove-log4j srcfile="@{jar}"
dstfile="@{destdir}/no-log4j-${jarfile-@{jar}}"/>
</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: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: Local Properties
Posted by Peter Reilly <pe...@gmail.com>.
On 8/28/07, Stefan Bodewig <bo...@apache.org> wrote:
> On Mon, 27 Aug 2007, Peter Reilly <pe...@gmail.com> wrote:
> > On 8/27/07, Stefan Bodewig <bo...@apache.org> wrote:
>
> >> How does nesting of locals work? If a macro calls another macro,
> >> are the properties set in the outer macro available to the inner?
> >> What about <ant> subbuilds invoked from inside a macro?
> >
> > Nesting works for calling other macros (otherwise ant-contrib for
> > would not work too good!).
>
> OK.
>
> > But not for calling ant subbuilds invoked from inside a macro.
> > The reasoning here is that 1) the code is awful (and thus hard to
> > maintain) and 2) it is not necessary as one can use nested
> > <property> tags on the <ant> task and 3) it may be confusing (where
> > do these fit with nested property, user and non-user properties).
>
> 2) implies that I'm aware there is a local property around. I know I
> am probably constructing something unlikely to happen, but I'm trying
> to understand what would happen before I dive into the code.
>
> Given
>
> <target name="echo">
> <echo>In antcall: ${foo}</echo>
> </target>
>
> <macrodef name="inner">
> <sequential>
> <echo>In inner: ${foo}</echo>
> <antcall target="echo"/>
> </sequential>
> </macrodef>
>
> <macrodef name="outer">
> <sequential>
> <make a local property "foo" and set it to "baz"/>
> <inner/>
> </sequential>
> </macrodef>
>
> <target name="callWithMacro">
> <property name="foo" value="bar"/>
> <outer/>
> </target>
>
> would result in
>
> In inner: baz
> In antcall: bar
>
> Correct?
Yes:
callWithMacro:
[echo] In inner: baz
echo:
[echo] In antcall: bar
>
> By just looking at inner and not at the path it gets called you can't
> know that a local property exists.
>
> I don't say this is a big problem, but I can see how it is going to
> confuse people. At least we need to document it properly - or find a
> non-awful way to make it work 8-)
Everything to do with <antcall>, <ant>, <subant> etc is a nightmare, I would
rather deprecate the whole lot and replace them with macros (antcall) or
with calls to a new jvm (for <subant>).
In any case, if local properties are to be inherited, the properties defined
in the <property> element of the <ant> task would have to take precedence
over the inherited local-properties.
Peter
>
> >> I think there are two options: restricting it to sequential or
> >> allowing it for any TaskContainer.
> >
> > This is hard as the TaskContainer user implementation controls when
> > the sequence of UEs are to be invoked (or reinvoked) and there is no
> > hook back to ant core as to when this happens.
>
> OK, so I really need to read the code before I comment any further.
>
> Stefan
>
> ---------------------------------------------------------------------
> 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
Re: Local Properties
Posted by Stefan Bodewig <bo...@apache.org>.
On Mon, 27 Aug 2007, Peter Reilly <pe...@gmail.com> wrote:
> On 8/27/07, Stefan Bodewig <bo...@apache.org> wrote:
>> How does nesting of locals work? If a macro calls another macro,
>> are the properties set in the outer macro available to the inner?
>> What about <ant> subbuilds invoked from inside a macro?
>
> Nesting works for calling other macros (otherwise ant-contrib for
> would not work too good!).
OK.
> But not for calling ant subbuilds invoked from inside a macro.
> The reasoning here is that 1) the code is awful (and thus hard to
> maintain) and 2) it is not necessary as one can use nested
> <property> tags on the <ant> task and 3) it may be confusing (where
> do these fit with nested property, user and non-user properties).
2) implies that I'm aware there is a local property around. I know I
am probably constructing something unlikely to happen, but I'm trying
to understand what would happen before I dive into the code.
Given
<target name="echo">
<echo>In antcall: ${foo}</echo>
</target>
<macrodef name="inner">
<sequential>
<echo>In inner: ${foo}</echo>
<antcall target="echo"/>
</sequential>
</macrodef>
<macrodef name="outer">
<sequential>
<make a local property "foo" and set it to "baz"/>
<inner/>
</sequential>
</macrodef>
<target name="callWithMacro">
<property name="foo" value="bar"/>
<outer/>
</target>
would result in
In inner: baz
In antcall: bar
Correct?
By just looking at inner and not at the path it gets called you can't
know that a local property exists.
I don't say this is a big problem, but I can see how it is going to
confuse people. At least we need to document it properly - or find a
non-awful way to make it work 8-)
>> I think there are two options: restricting it to sequential or
>> allowing it for any TaskContainer.
>
> This is hard as the TaskContainer user implementation controls when
> the sequence of UEs are to be invoked (or reinvoked) and there is no
> hook back to ant core as to when this happens.
OK, so I really need to read the code before I comment any further.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: Local Properties
Posted by Peter Reilly <pe...@gmail.com>.
On 8/27/07, Stefan Bodewig <bo...@apache.org> wrote:
> On Wed, 22 Aug 2007, Peter Reilly <pe...@gmail.com> 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)
>
> Still haven't found the time to actually look at the implementation,
> sorry.
>
> > 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.
>
> And they are a good idea for this.
>
> How does nesting of locals work? If a macro calls another macro, are
> the properties set in the outer macro available to the inner? What
> about <ant> subbuilds invoked from inside a macro?
Nesting works for calling other macros (otherwise ant-contrib for would
not work too good!).
But not for calling ant subbuilds invoked from inside a macro. The
reasoning here is that 1) the code is awful (and thus hard to maintain)
and 2) it is not necessary
as one can use nested <property> tags on the <ant> task and 3)
it may be confusing (where do these fit with nested property, user and
non-user properties).
>
> > The <local> patch uses the following elements for block scopeing -
> > <target> and <sequential>.
> >
> > (I think that this could be restricted to just <sequential>).
>
> I think there are two options: restricting it to sequential
This is my current
> or
> allowing it for any TaskContainer.
This is hard as the TaskContainer user implementation controls when
the sequence of UEs are to be invoked (or reinvoked) and there is no
hook back to
ant core as to when this happens.
>Anything else will make us add
> more tasks to the list of allowed containers.
It would be up the the custom taskcontainers to demark the
localproperty context.
Peter
>
> Stefan
>
> ---------------------------------------------------------------------
> 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
Re: Local Properties
Posted by Stefan Bodewig <bo...@apache.org>.
On Wed, 22 Aug 2007, Peter Reilly <pe...@gmail.com> 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)
Still haven't found the time to actually look at the implementation,
sorry.
> 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.
And they are a good idea for this.
How does nesting of locals work? If a macro calls another macro, are
the properties set in the outer macro available to the inner? What
about <ant> subbuilds invoked from inside a macro?
> The <local> patch uses the following elements for block scopeing -
> <target> and <sequential>.
>
> (I think that this could be restricted to just <sequential>).
I think there are two options: restricting it to sequential or
allowing it for any TaskContainer. Anything else will make us add
more tasks to the list of allowed containers.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: Local Properties
Posted by Peter Reilly <pe...@gmail.com>.
On 8/22/07, Matt Benson <gu...@yahoo.com> wrote:
> 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?
I actually have not yet tested this part. ----)
But the way it is meant to work (and maybe it does work)
is that all threads get a reference to the stack from
the parent thread (a lot of threads get created for
example with IO processing of sub processes),
but for these cases there is only one ant thread
creating and destroying macroinstances.
For parallel, the idea is that a shallow copy is made of
the property stack and this is set to the threadlocal value
so that each the parraled threads would
have own copy of the stack.
Peter
>
> -Matt
>
> --- Peter Reilly <pe...@gmail.com> 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="jarfile-@{jar}" file="@{jar}"/>
> > <remove-log4j srcfile="@{jar}"
> > dstfile="@{destdir}/no-log4j-${jarfile-@{jar}}"/>
> > </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:
> > dev-unsubscribe@ant.apache.org
> > For additional commands, e-mail:
> > dev-help@ant.apache.org
> >
> >
>
>
>
>
> ____________________________________________________________________________________
> 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: 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
Re: Local Properties
Posted by Matt Benson <gu...@yahoo.com>.
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 <pe...@gmail.com> 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="jarfile-@{jar}" file="@{jar}"/>
> <remove-log4j srcfile="@{jar}"
> dstfile="@{destdir}/no-log4j-${jarfile-@{jar}}"/>
> </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:
> dev-unsubscribe@ant.apache.org
> For additional commands, e-mail:
> dev-help@ant.apache.org
>
>
____________________________________________________________________________________
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: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org