----- Original Message ----- From: "Stefan Bodewig" <[EMAIL PROTECTED]> > Has anybody of you (those of you pushing for property immutability in > the core) had a look at what we decided upon when we put together out > Ant2 requirements? I'm talking about > > * make properties fully dynamic, i.e. allow their value to be reassigned
The quote I see is: "It will be possible to reassign values of properties via a built-in task." This came from http://jakarta.apache.org/ant/ant2/features.html - is this the definitive reference for Ant2 design? > Erik, I really appreciate all the work that you have done and you've > cleanup up a lot of Ant's core classes a fair bit with it, but maybe > we are really going one or two steps too far? Oops.... I hope not. I'm with Jose (yeah, two non-committers causing trouble! :) on this one as far as the declarative nature of Ant goes. The overridability (thats a bad term since its really the first to set wins) is one of the most powerful and pleasant features of Ant 1.x (1.3+ is my experience, so not speaking for earlier versions!). I don't know how its planned to handle allowing properties to change, and its hard to visualize just design documents even if this is spelled out - I'd like to see a more concrete example of any kinds of scoping and overridability and how that would play out in Ant2. > We want to leave <property> as task the way it is, OK. We probably > also want to make all property setting core tasks behave the same way. > But do we really want to enforce property immutability as a core > feature? I think enforcing at the API level is the way to go. Tasks shouldn't be allowed to override properties. I do feel a bit less-strong about things like <available> and <condition> since I'm really asking "is this file present?" and if the property is previously set then the answer I get is not necessarily accurate - but you can see a warning go by and re-using property names is discouraged, and I can see benefit to being able to override such things with -D to force something through. > Our vote in April/May quite clearly says no, and at least > mine still stands. I don't read the above quote so strongly. It says a "built-in" task can reassign properties - this is currently possible except with a warning. And perhaps with some more refactoring a more privileged way of setting properties could be created and prevent general tasks from doing so at the API level yet allowing other constructs the capability. > Having said that, let's rework the last patches so that existing core > tasks don't override existing properties but there still is an API to > modify properties. I think all core tasks except <available> have been reworked to call setNewProperty. setProperty still overrides existing properties, except issues a warning. The warning could be removed if thats too annoying and we could just be careful not to use that API call for built-in/optional tasks (unless desired for some reason). > Consider this a -1 against the functionality of enforcing property > immutability in the core. *ugh* :) Erik -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
