ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Bodewig <>
Subject Re: local properties
Date Thu, 14 Oct 2004 09:26:56 GMT
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/taskcontainer.
> Example:
>    <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">
    <local name="prop" value="a local value"/>
    <echo>prop is ${prop}</echo>

but I'm repeating myself.  I have no new arguments to add.

> 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?

> 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.

> 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.


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

View raw message