ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jose Alberto Fernandez" <j_a_fernan...@yahoo.com>
Subject RE: Scope of Types
Date Fri, 01 Jun 2001 13:11:24 GMT
> From: Conor MacNeill [mailto:conor@cortexebusiness.com.au]
>
> 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.
>
> Lets say, project A defines a property
>     <property name="build.dir" value="BuildAreaA"/>
>
> I believe B, as the referring project, should be able to
> override this. I
> had envisaged this as
>     <property name="A:build.dir" value="BuildAreaB"/>
>
> But that implies that properties (and other data values) are somehow
> mutable. I have thought about a precedence model for this, where an
> referring project has higher priority than the referred
> project. This would
> give a precedence like this
> Commandline -> Project C -> Project B -> project A
>
> This gives some controlled mutability but I'm not sure about
> it - seems
> complex to maintain the precedence of each data value.
>
> I think Jose Alberto will suggest that we supply the
> overriding properties
> as part of the <projectref>, like this.
>    <projectref location="A.ant" name="A">
>        <param name="build.dir" value="BuildAreaB">
>
> Hmm, I have approached projectref as a parse time operation where the
> project hierarchy is built up in the project model and not an
> execution
> time operation. I guess I can still accommodate that at parse time. I
> wonder when the values would be set. In mutant, before any targets are
> evaluated all the non-target tasks are executed as part of an
> initialization phase - primarily to set up data values. Once this
> initialization is finished, the referring project's overrides could be
> applied.
>
> Thoughts?
>

My thought about <projectref> is that they should be treated quite simillar
to <taskdef> or some of the type definitions we have today. That is, the
call (declaration?) should have access to any properties defined at that
point in the <project> level elements.

So with that in mind, the way I think it should work is that while executing
the initialization phase of "C" when it find <projectref "B"> it will set
the properties in the params of the instantiation and then call the
initialization of "B".

The difference with what you are proposing is that by doing it this way you
are not only affecting the values of the properties you are passing, but
those of all other properties in "B" that use the that property to construct
its own values:

	<property name="build.file" value="${build.dir}/thefile.txt" />

if override at the end, ${build.file} will get the wrong content with
rrespect to ${build.dir}.

Jose Alberto


Mime
View raw message