ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Conor MacNeill" <co...@cognet.com.au>
Subject Re: Scope of Types
Date Fri, 01 Jun 2001 13:04:52 GMT
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.

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 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.

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. 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>

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

Am I babbling ?

Conor



Mime
View raw message