> 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: http://www-106.ibm.com/developerworks/library/j-antbuild/?n-j-1261 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" classname="com.ibm.samples.apache.tools.ant.taskdefs.optional.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> <propertyprompt propertyname="servletDirectory" defaultvalue="/usr/servlets">Where should servlet classes install </propertyprompt> </target> </project> 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. -Steve -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
