ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Conor MacNeill" <>
Subject RE: Lions, Import, and ProjectRef, oh my !
Date Wed, 13 Jun 2001 23:35:08 GMT
> From: Peter Donald []
> 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.


View raw message