From: "Stefan Bodewig" <[EMAIL PROTECTED]>
> This is not about the mutability of properties. We'd need a separate
> thread here and I don't want to start too many on one day, especially
> after four months of silence 8-)
>
Can't wait! :-)
> Possible scopes for properties:
>
Thinking about that I'd suggest just having the following:
1) Project-level scope: properties available within the project (they may
span more than one buildfile by using <projectref>)
2) Container scope, defined by a TaskContainer. Definitions in there
will disapear at the end of the container. What should be the behaviour
with respect to redefinitions?
<property name="A" value="1" />
<begin> <!-- starts a new scope -->
<property name="B" value="2" />
<property name="A" value="${B}" />
<echo message="The value is: ${A}" />
</begin>
Should it be: "The value is: 1" or "The value is: 2" ? Shall we override or not?
3) Invocation scope: what we have called user-properties in the past.
Implemented by <param> on <ant*>. The value takes precedence from
any definitions in the project being called (just like ANT1).
Parameters in command line follow the same rules.
I really do not believe on the blind inheritance of properties. It assumes
that any project being called will use the same properties with the same
name in the same way as the caller. Which violates any rules about modularity.
Finally, there is the issue of how to get values back from an invocation. How
can that be worked out without violating either modularity or inmutability?
I have been thinking on a form of return-values for <ant*> calls. The idea is
something like:
<ant .....>
<param name="subdir" value="${mysubdir}" />
<param name="theFiles" idref="myFileSet" /> <!-- passing a DT as
parameter -->
<returns name="calleeProperty" as="myProp" /> <!-- defines myProp on
return -->
</ant>
All tasks that define something (<property>, <type>, <available>, etc. Will act
on a current
scope provided by the container. The scoping and overriding rules will be
enforced by ANT
ant not the individual tasks as it is today.
Thoughts?
Jose Alberto
> (1) Hierarchical scope - properties that are available everywhere in
> the build file that defines them as well as in all subbuilds that are
> invoked from this buildfile (and subbuilds invoked from subbuilds and
> so on). This basically is the Ant 1.x model, as long as we leave the
> inheritall attribute of <ant> aside.
>
> (2) Global scope - properties that are available throughout the whole
> build process. The difference to (1) would be that subbuild defined
> properties could be accessed in the parent build file.
>
> (3) Build file scope - properties that are available everywhere in the
> build file that defines them, but not in subbuilds - this is Ant 1.x
> with inheritall="false" on <ant> tasks.
>
> (4) Target scope - properties that are available only in the target
> that defines them.
>
> (5) Container scope - even finer grained than (4) for things like
> <parallel> or similar.
>
> Are there other scopes? Which of these do we really need?
>
> We should think about syntax, after we've decided which scopes we need
> to cover by syntax IMHO.
>
> Stefan
>
