Trying to consolidate a few answers since I'm very late to the party
anyway.
On Fri, 08 Oct 2004, Peter Reilly <[EMAIL PROTECTED]> 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">
<let>
<local name="prop" value="a local value"/>
<echo>prop is ${prop}</echo>
</let>
</target>
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 <[EMAIL PROTECTED]>
wrote:
>> 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.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
