> From: Stefan Bodewig [mailto:[EMAIL PROTECTED] > > On Fri, 15 Oct 2004, Jose Alberto Fernandez > <[EMAIL PROTECTED]> wrote: > > > I just want to say that in my proposal, the temporary > properties only > > last for as long as the Project instance is executing. > > I know, still that might be too much. GridAnt is one such > case, and I think there's been some kind of "incremental > build" proposal that would rerun the same Project instance > over and over again. Let's simply accept that people are > doing weird things with Ant 8-) >
And there are plenty of tasks out there that do weird things with properties but still within the current ANT demarcation. How many of those will have to be retrofitted in order for they to work correctly with these locals? For example, the usage of ThreadLocals in other proposals may be right for some things, but it may be wrong if I am trying to use properties to communicate between threads. (Which I can do with regular properties). > > How do you use <local/> in conjunction with <condition/>? > > For this to work, you need a way to declare the property without > > defining it, but shadowing any previous definition of such property. > > Exactly. That's what I had in mind. > Well as someone else pointed out. It is not only shadowing of property names that you need, but also of entire property prefixes since you have tasks in ANT like <property environment="env"/> which load an entire family of properties. So the story is still not that simple. BTW, a long time ago I went on proposing something like this, to have a real stack of property definitions, shadowing, and so on. But there are a lot of funny issues that made it very dificult and a lot of compatibility things. This is why I am proposing an initial simpler model. Notice that this does not mean we cannot have <local/> in the future. One does not preclude the other. > > As per my proposal, if the extended life of properties is > considered > > such a major issue, I am sure the implementation can be > easily changed > > to remove the property once the scope of the <let> i.e., > <macrodef/> > > is exited. > > It would certainly help me. > > > The reason I do not do it, is because <let/> does not define a > > property, it just define a new name for one. And it is up > to the usage > > of our regular tasks to decide to define it or not. But notice that > > one could use the name created by let, for anything else, > not just a > > property. > > I see - but it would need to get communicated back in order > to be used outside of the macrodef's scope. > True, and it can be easily done. > > But we could add a way to say, "clean any property of this name on > > macrodef exit", that would be quite easy to do, I think. > > And make it the default behaviour? > As I said, it is not as simple, you may have created a reference, or use the name for loading environmental info. or <loadproperties/>. I am not sure a blanket policy of "look for this name on any possible way it may bave been used and remove it" makes much sense. It is like guessing. Maybe if the user gives a hint on how it will be used, then it may make sense. And if there is no hint, there is no auto-cleaning. <let name="foo" usage="property,property-prefix,reference"/> This will cause <macrodef/> to try to clean on all those spaces on exit. But if you do not declare an usage, then there is no cleaning. Which may be a completely valid requests that should be possible to express. Jose Alberto --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
