----- Original Message ----- From: "Stefan Bodewig" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, September 05, 2000 8:54 AM Subject: Re: Overwriting Properties
> >>>>> "MBA" == Michael B Allen <[EMAIL PROTECTED]> writes: > > MBA> Why can properties not be overwritten? > > Because of a couple of "historical" reasons. There is a good chance > that property behavior is going to change again. > Is there a summary available with the decisions (made by you/the list) on the "change of property behaviour"? My thoughts were going in the following direction: - Global properties at project-level are evaluated at parse-time and are unchangeble - "local" properties are declared inside a target and are executed like every other task (if execution comes to them) and are changeble. - For "called" build-files properties should maybe get overridden iff they are nested inside the ant-task, but not if they are declared in the sub-build-file on a global level? This would allow to set "constant" values at the top of the build-file without the possibility to accidently change them and it allows you to have variable properties do decide on the "flow" of the build-file (I think you don't like this word "flow"? :-) ). This would allow for the thing I'm doing with ant (and several antcall's because of the unchangeble state of properties and the way they are evaluated currently): Have a "large" Build-file which "executes" the build for several sub-projects. For each of them it tries to get (from VSS) something with a specific label and if it was succesfull go on with compile, junit, doc, jar, ... Additionally I'm using the - no yet commited - PropertyFile-Task to increment the build-number on each run. Using the result of the evaluation is difficult, because all properties are already resolved before running this specific task. (Will PropertyFile get sometime into CVS?) Just my thoughts (and questions) Nico
