Agreed.... thats why I'm bringing this up.
But if we let <tstamp> change properties, then why not <available> and <condition>?
If we let everything change properties then we might as all be writing our build scripts in Perl! :)
Don't get me wrong, I can understand and appreciate why you'd want properties to be immutable despite the counterintuitive behavior it produces for users to deal with, such as setting local properties before global ones. That's just an education problem.
I can also understand why there is debate around <available> and <condition>. In some sense, if the property is set before the task is run then the configuration of the build is incorrect in some way, since that should never be necessary save as a hack to get around immutable properties. It comes down to whether you want to make life easy on the user with an incorrectly set up build, or enforce the rigors of your paradigm. I tend to favour ease of use, but I'm funny that way.
But with <tstamp> and its properties, you have something very different. These properties are not set by the user but are constants within the program. <tstamp> is really a way of declaring "Give me the time now", and it just so happens that the way that time is communicated is through 3 standard properties controlled completely by the task.
In a way, this becomes very similar to what WebDAV calls "Live Properties" and "Dead Properties". The live ones are generated by the server, the dead ones are under the user's control.
Hmm. Just thinking out loud, but suppose that Ant adopted something similar. There are user controlled properties, called Dead properties, and Ant system properties which are Live. The system will never affect Dead properties, the user cannot affect Live ones. The only thing the user can do to a Dead property is give it an initial value. The system can choose to do anything that is appropriate with Live properties, and it registers its built-in properties as Live before it parses anything from the user.
That provides some of the separation between properties you seem to have been looking for and clarifies why some of them might change in some circumstance. Any task can choose whether to allow changing a Live property, but it guarantees that a property specifically set by the user will not be changed in any way.
That begs the question of whether a property specified in an attribute to a task is a Live or a Dead property (other than the <property> task which produces Dead properties by definition). But by giving you a clear stopping point on the slippery slope you are worrying about, you should be able to decide that question based on what feels like the right answer rather than worrying about how you can explain the difference to users.
-- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
