ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Conor MacNeill" <co...@ebinteractive.com.au>
Subject RE: Some Thoughts on Ant 1.3 and 2.0
Date Thu, 02 Nov 2000 01:06:42 GMT
Duncan,

> >
> > Conor's approach to explicitly list the properties you want to pass
> > down to a sub project might be even simpler and clearer.
>
> Maybe, but the approach as stated would map exactly to how env
> vars work in
> Unix with processes/subprocesses. I'd rather map to this than have more
> machinery in place that tells what variables are passed where.
>

I think adopting the env var model is fine, but it really implies to me that
properties must be mutable in the sub-build just as env vars are in Unix
subprocesses. Also, I think Unix processes can use procedural logic to
decide what to do when a environment variable is already set. There are even
special syntax such as ${parameter:-word} for conditionally setting
properties. Would we need these in ant?

If we adopt mutability of properties then we lose the ability for the
command line or parent build to override the values set up in the subbuild.
This was the original reason that properties were made immutable IIRC.

We also have the issue of managing the property namespace to avoid name
conflicts. I think this can be a problem with Unix environment variables
too.

In general, I always like things to be explicit. You know that what you read
in the build file will be what is sent to the subbuild. Implicitly copying
all properties means I cannot know what gets sent to the subbuild. I guess
the model I am advocating is the method-call model - no side effects.


> >>> (2) Do we want mutable properties or not?
> >
> > JDD> Yes.

Just to be clear we are taking mutability at the <property> tag level. There
has always been property mutability at the script and task level. For
example this would work as expected.

<property name="x" value="hello"/>
<property name="x" value="${x} goodbye"/>

>
> But -- properties should only be scoped at the project level --
> and defined
> at the project level.. :)
>

I agree but I think it is too late for that. Without mutability people
wanted to control to what value some properties get set and they did that by
scoping property tags within targets. Many examples existed, including some
Tomcat build files IIRC, that led people to believe that properties could be
scoped in that way. There were many surprises when this did not work. The
feedback, I think indicated that people really did want properties to be
scoped. It will be difficult to take that away.

Conor


Mime
View raw message