ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jose Alberto Fernandez" <>
Subject RE: local properties
Date Tue, 19 Oct 2004 10:55:37 GMT
> From: Stefan Bodewig [] 
> On Fri, 15 Oct 2004, Jose Alberto Fernandez 
> <> 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

BTW, a long time ago I went on proposing something like this, to have a
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:
For additional commands, e-mail:

View raw message