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]