ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Steve Loughran" <>
Subject Re: Immutability
Date Sat, 08 Dec 2001 03:20:21 GMT

> Judging from the vote of March/April, the list contains almost all
> active committers of that time.  I haven't seen any committer except
> you and me show any opinion this time.  Steve said:
> >> I think this one will have to be opened up for some consensual
> >> decision making.
> which didn't happen, and he didn't show what he'd prefer.

I prefer simplicity, consistency and not breaking other people's builds. I
like the 'always immutable' rule for its simplicity, but note that I am not
above using <antcall> to get around it, and have encountered one issue in a
build file where i had to run ant twice to get a change out (incrementing a
version number in an SCM controlled property file and using the same version
number in the build)

till last week's setNewProperty() method, all tasks or scripts which set a
property had to use setProperty. This doesnt mean that they (we!) were going
out of our way to overwrite stuff, just that the sole entry point didnt
implement immutability.

New tasks can now choose whether to use the mutable or the immutable entry
points. but what about the existing ones? We cant tell from setProperty()
whether any overwrite is an accident or deliberate.

Really we want everyone who used setProperty() in a task without knowing of
its side effect to move to setNewProperty(). So keeping a warning in there
would seem to work. If somebody really, really wants to set a property with
overwriting and no warning, then they can use the #3 method, the one that
isnt written yet, setPropertyMutably(name,value) which will also unset a
property if the value is null.

I was happy with the warning message, but I understand why Stefan pulled it.
However, it permits people to write tasks (and articles about them) such as
this little bunny here:

In this article the author (a) doesnt know when init() is called versus
properties assigned and then writes an input task which explicitly
overwrites properties assigned in advance

<project name="PropertyPromptExample" default="main" basedir=".">
  <property name="promptTimeout" value="10"/>
  <taskdef name="propertyprompt"

  <target name="main">
    <property name="documentRoot" value="/usr/apache/htdocs/sample"/>
    <echo>HTML/JSP pages installing to: ${documentRoot}</echo>
    <echo>Servlet code installing to: ${servletDirectory}</echo>
    <propertyprompt propertyname="documentRoot"
         promptcharacter=":">Enter value for web application document root
    <propertyprompt propertyname="servletDirectory"
        defaultvalue="/usr/servlets">Where should servlet classes install

By leaving setProperty() as is we let tasks like this continue unrestricted,
as well as permit existing script code do what was deliberately written by
people who did know what they were doing.

Finally, some scoping could ultimately sort things out. local immutable
properties would substitute for global mutables, which is effectively what
antcall provides today.


To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message