ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Reilly <>
Subject Re: local properties
Date Fri, 15 Oct 2004 10:35:14 GMT
Stefan Bodewig wrote:

>Trying to consolidate a few answers since I'm very late to the party
>On Fri, 08 Oct 2004, Peter Reilly <> wrote:
>>I have had a proposal outstanding for a while for local properties:
>a long while.
>My preferences haven't changed much over time, but I'm far too busy to
>help getting this to a conclusion.  My current work schedule would
>prolong any kind of discussion for an unreasonable amount of time.
>I think we need to address the problem of temporary properties inside
>macros in some way and prefer a solution that doesn't leave us with
>tons of new and unused properties.  If I can't get it my way, read "if
>I can't convince you", I'd rather see your solution implemented than
>keep the status quo.
>>1) Syntax The proposal adds a local property to a enclosing
>>   <target name="example">
>>       <local name="prop" value="a local value"/>
>>       <echo>prop is ${prop}</echo>
>>   </target>
>>   <macrodef name="t2">
>>       <attribute name="file"/>
>>       <sequential>
>>         <local name="dir"/>
>>         <dirname property="dir" file="@{file}"/>
>>         <mkdir dir="${dir}"/>
>>         <touch file="@{file}"/>
>>       </sequential>
>>    </macrodef>
>>I think it is nicer to do this rather that having an explicit local
>>property container,
>Nicer?  Maybe.  I still think a special task container would be
>cleaner since it provided explicit scoping and might even help us
>route around the "custom PropertyHelpers problem".  Something like
><target name="example">
>  <let>
>    <local name="prop" value="a local value"/>
>    <echo>prop is ${prop}</echo>
>  </let>
>but I'm repeating myself.  I have no new arguments to add.
Since we are really only worried about the macrodef usecase, we could
initially just deal with this using the syntax:

<macrodef name="t2">
   <attribute name="file"/>
   <localproperty name="dir"/>
        <dirname property="dir" file="@{file}"/>
        <mkdir dir="${dir}"/>
        <touch file="@{file}"/>

I.e have a local nested element for <macrodef> - this syntax has
of course been discussed previously.  We can leave the gate open
to allow other third-party containers to use local properties -
like the <let> container in your example, or the <for> task from
ant-contrib or the <foreach> task from antxtras. This could be done
by providing the java api to create localproperties. Implementing
all containers to support local properties could be at a later
stage - if there is a demand (unlikely).

The local properties should I think be in thread-local storage to
avoid conflicts between multiple threads, so I think that PropertyHelper
needs to be modified to do this.

>>2) Shadowing of properties
>>The proposal allows local properties to shadow normal and user
>>properties.  I feel that this is necessary to allow macrodefs to be
>>written without them failing sometimes.
>Can you expand on this please?  Whyt kind of macros would require
>shadowing in order to be writable?
There are two reasons for this

1) Macrodefs are normally hidden - say in imported files or in an antlib,
   so one may not know what names they use for local properties. Normal
   programming languages allow scoped variable names to override the global
   names to allow this isolation. If user properties names overrode the
   localnames, the <t2/> example above would really not be able to use
   a nice small name like "dir" for the localproperty name, but would have
   to adopt a convention like "t2_dir" for the name, and hope that no one
   will use ant -Dt2_dir="not a nice dir". Jose's approach does not have
   this problem - but it does come at a cost (hidden names).

2) the user explictity say that the name is a local property. It seems
   reasonable to expect that the property that is used is local and not 
a global
   property (this is probally the same argument as 1) :-[  )

>>3) Extent of local properties
>>local properties will be inherited to child projects (if inheritall
>>is true).
>Fine with me.
>On Fri, 8 Oct 2004, Jose Alberto Fernandez <>
>>>2) All these uniquely named properties go on living after
>>>   the macro has executed. That pollutes the namespace.
>>Yes it does. But I still have to see a good argument on why shall
>>that bother anyone. Unless you are talking about millions of
>>executions within one project context.
>Hmm, ask Steve how long a SmartFrog instance is running.  And AFAIU
>NetBeans 4 runs a single instance of Ant as long as the IDE is
>running.  This may really lead to quite a few properties at the end of
>the day, in particular if you need to pass them to a forked JUnit VM
>or down to a child build with inheritall set to true.
Jose's solution could be modified to remove the properties on exit
from the macrodef. - but this would need to be made thread-safe.

>>My worries with these other solutions are that they not only touch
>>macrodef and propertyHelper, they modify target, ant, sequential,
>>parallel,and several other tasks.
>That's why I'd prefer the explicit TaskContainer.  It shouldn't be
>necessary to touch target, for example.
I do not agree, but like I said above this is not needed for the 
macrodef use case
so it can be dropped from the proposal.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message