ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Duncan Davidson <>
Subject Re: Property substitutions, Contributed Tasks, & New features
Date Fri, 12 Jan 2001 23:37:04 GMT
On 1/12/01 4:11 AM, "Conor MacNeill" <> wrote:

> I don't find the analogy too compelling. but I assume you mean <property>
> would not override a command line value, but <setproperty> would?

Something like that... More accurately would be to say that properties set
on the command line would override the <property> tags. Since <setproperty>
would be something happening as a Task, then it can reset whatever it wants.

The problem with having mutable vs immutable properties is that they are
really two different data stores. Or, a a single data store with a set
beside them that indicates immutable props.. Of course, when those props
were attempted to be tweaked, then a NoChangePossibleException would have to
be thrown (and expected by the setter).

> When I am doing a build, I want to be able to control certain properties
> and not have the build file just ignore them. As the build runner I want
> priority over the build writer. The build.compiler flag would be a good
> example, but even build specific properties should be controllable from the
> command line. To have to edit the build file to change one of those values
> would be a chore.

Seems to me that there is an uneasy balance between build runners and build
writers. At the end of they day they have to cooperate to some degree.

> The same issue comes up with sub-builds. Which build controls the values,
> parent or child?

If we go Workspace/Module -- then this issue is factored out. But then we
also get into the problem of how to scope build flags such as build.compiler

James Duncan Davidson                              
                                                                  !try; do()

View raw message