> From: Peter Donald [mailto:[EMAIL PROTECTED] > > Well - I can't recall ever seeing a build file with properties that come > after the first <target> element. If I did come across such a build file I > would almost definetly get confused because I don't look for properties > intermingled with targets. I guess I would just like to get rid > of the most > uneeded flexability as possible. >
Probably true. I think I know where you are coming from with some of this stuff. I hadn't felt the need to fix the order of elements in the build file but I do definitely see the need to restrict some operations to parse time (Project model construction time, more generally) and others to execution time. In particular, in mutant <projectref>'s location attribute is a parse-time attribute and therefore not subject to property expansion. The <include> element is similar. These cannot be execution time attributes without losing (or complicating) separation of parsing and execution. That does not necessarily mean that <projectref> couldn't have nested elements that are evaluated at execution time and perform some execution time control of the referenced project - I'm not sure. 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. 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. Cheers Conor
