ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Donald <>
Subject RE: Lions, Import, and ProjectRef, oh my !
Date Thu, 14 Jun 2001 03:31:14 GMT
At 09:35 AM 6/14/01 +1000, Conor MacNeill wrote:
>I see <import> as a execution time operation, so it would be implemented as
>a task and have property expansion applied, even if I see that as having
>dubious value.

I am curious why you see it as a execution time feature. I see it in much
the same way as I see imports in java. Thus I don't see it as execution
time but post-parse, pre-execution time ;)

>Lets discuss, without too much aggro hopefully, if, why and how one project
>may control another that it references via a <projectref>. As a simple
>scenario, lets say I want to change the value of a property, build.dir, in a
>referenced project, so that I could combine a number of builds into one
>build location. It seems a reasonable scenario to me. I think this will cut
>across a number of issues including project to project control, scoping and
>immutability of properties, etc.

Well I don't see projectref as offering any control what-so-ever ;) Two
reasons mainly;
* I can not see any logical way of doing it (without causing anomalies,
contradictions etc)
* We can always do it via another mechanism

The original reason for supporting the construct was for something like the
following case

Consider the Projects A, B, C and D. A depends apon B and C, B depends upon
D and C depends on D. In Ant1 there is no real way of supporting this as
the DAG is restricted to one project. In standard implementation project D
would be built twice (once from B and once from C). You could hack it
together by creating another project that ant-calls the projects in desired
order but this quickly gets out of hand. X-project DAG would however make
this trivial.

Now lets say we allow properties to be set via projectref. How do we do it?
We could scan the whole project tree (which would require all of them
simultaneously loaded) and search for parameters to each build file. 

A few hard problems arise from this;
* what if different projects set the same property but to different values?
* what if projects set different properties that are incompatible?
* how to we determine what values of the properties are passed 
  - are they the values at the time of first execution? which would cause
    inconsistencies depending on if the project is run free standing or 
    because of proejectref. (ie one project may be passing uninitialized 
    properties because it hasn't run yet)
  - do we synchronize all projects up to point where they call project?
    (This would be an implementation nightmare and in some cases impossible).
  - some other method?

Theres other problems that arise but the above should give you an overview
of the sorts of problems that this approach will lead to.



| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof."                   |
|              - John Kenneth Galbraith               |

View raw message