At 12:28 AM 6/13/01 +1000, Conor MacNeill wrote: >> What you describe as projectref is not a project reference. It is >> generation of a project instance from a project template based on >specified >> parameters and subsequent modification of current project model to link >it >> to generated template instance. I use projectref to mean a reference to >> another project. > >Whatever you choose to call it, I believe it will be necessary for the >referring project to be able to control the referenced project in some way. >Have a look at the original thread where I introduced <projectref>. One of >the suggestions then was that <param> elements in the projectref element >gave the referring project its mechanism to control the referenced project >without resorting to mutable or scoped properties. How do you propose to >achieve that control?
I don't see projectref as doing any control. It is simply a reference to allow cross project file DAGs. Control if required can be provided by other mechanisms. Templating will also be provided by other mechanisms. >> >You should always be able to define <properties> before anything else. >> >> Why? properties will never be expanded in projectrefs or imports. >> > >That is not clear to me. > >Also, I do not yet see the need to impose an order on the elements in the >build file. What advantage do you see in not formalizing order? >BTW, can we have meaningful subject lines? What is the meaning of the Lions >reference? It is meaningful - it is a comment on the state of ant-dev via reference to a classical film ;) Cheers, Pete *-----------------------------------------------------* | "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 | *-----------------------------------------------------*
