> From: Conor MacNeill [mailto:conor@cognet.com.au]
>
> From: "Conor MacNeill" <conor@cortexebusiness.com.au>
> To: <ant-dev@jakarta.apache.org>
> Sent: Friday, June 01, 2001 10:46 PM
> Subject: Re: Scope of Types
>
>
> > From: "Conor MacNeill" <conor@cognet.com.au>
> > >
> > > Anyway, some further thought is required on this in relation to
> <antcall>
> > >
> >
> > OK, here is some further thought. It is somewhat
> conditioned by what I
> have
> > done in mutant.
> >
> > Lets say we have this projectref structure
> >
> > // project A
> > <project>
> >
> > // project B
> > <project>
> >    <projectref location="A.ant" name="A"/>
> >
> > //project C
> > <project>
> >    <projectref location="B.ant" name="B"/>
> >
> >
> > In mutant, there will be three, linked execution frames -
> one for C, one
> > for B and one for A. Each execution frame has its own copies of data
> > values, task definitions, etc. There are two issues I want to talk
> about -
> > one if property scoping and the other is antcall.
> >
>
> OK, so now let me deal with <ant> and <antcall>. In Ant1 the whole
> environment of the caller is passed to the called instance.
> This is like
> the shell environment model in Unix. The interaction of name
> collisions and
> property immutability makes operation of this often
> unworkable. You can't
> really call arbitrary targets in other build files without
> making sure that
> your definition of "src.dir" won't interfere with the other
> build. The use
> of common names such as these exacerbates the problem.
>
> I prefer an explicit param passing model where selected
> values from the
> caller's environment as passed to the called environment. I'd
> like to know
> if there is general agreement about this.
>

A am 100 pct for that. The only wigle room I would give is that it may be
possible to follow the MAKE model, in which you inherit all values from the
caller, but they do not have precedence over local redefinitions. That is
your local project can change them. With of course the exception of things
passed with <param>.

This is an intermediate model, not as strict, but it allows for having some
form of default values for things like ${build.compiler} and such, which
have global meaning.

> Now consider a scenario where an <antcall> in project C calls
> a target in
> project B
>
> <antcall target="B:compile">
>
> we are calling from an environment with three linked
> execution frames to
> one where there will be two.

I disagree on this. You are not calling project "B" the would be:

	<ant target="compile" location="B.ant" />

what you are doing is calling a target on the instantiation of project "B"
defined in "C" which is very different. In this case all the property
overrides made by "C" apply.

So you do have 3 execution frames. To me, <ant*> should be interpreted as a
shortcut syntax for calling recursively to java
org.apache.ant.Main -Dparam=val... <target>.
The fact that we do not create a new JVM is just an optimization. So all the
normal rules, should apply, and whatever additional optimization we do must
be consistent with the above semantics.

>I assume the two frames will be
> initialized
> normally, with A's values being set, then Bs, then B's overrides being
> applied and then overrides from the caller. (This can work in
> the opposite
> order - apply the callers values first (possibly setting
> values in B and
> A), apply B's overrides to A, initialize A (immutability
> preventing the
> override), then initialize B (again immutability preventing
> the caller's
> value being overridden).
>
> So, we could have
> <antcall target="B:compile">
>     <param name="A:build.dir" value="BuildAreaC"/>
>     <param name="build.dir" value="BuildAreaC"/>
> </antcall>
>
> OK, perhaps that is workable. Note that the passing of the whole
> environment is no longer really practical since it would not
> be clear how
> to map values from the three frames of the caller into the
> two frames of
> the called target.
>

Notice that that would not be an issue, the way I see it.

> Actually, a quick question - should project C only be able to
> manipulate
> values of the projects it directly imports, project B and not
> the values of
> project B's imports, project A.

I do not see much problem on allowing mutilevel access.

> The same goes for the usage
> of types. In
> other words, if project A defines a type <fubar>, can I use it in C as
>
> <B:A:fubar>
>

I am not sure whether XML will allow this syntax :-(

> or would B have to bring the type into it's namespace for it to be
> available to C?
>

Not sure if it would be best to have a general restriction, or to just
require imports for things XML does not allow.

Jose Alberto