On Fri, 25 Jan 2002, Peter Donald wrote: > > Are you kiding ??? Ant internals have changed between each 1.x release - I > > can hardly recognize things. > > Change is not the problem. Incompatible change is a problem.
And we had enough of that too. > > Could you explain this ? Except for adding a task that has the same name > > with a user-defined task, there's little else that can happen. > > hmmmm - you think? When Connor added the ability for addConfiguredX to behave > like addX except where component was "configured" prior to being added. This > would break any task that had an element named <configuredX/> - unlikely to > happen but possible. Any addition of a non-private method can also > potentially cause conflicts because a lot of people subclass ant tasks and > types. For instance when an extra method was added to the zip task it caused > some tasks in AValon project to break because the avalon tasks used same > attribute name. We also dropped support for certain XSLT Liasons because they > were based on dropped unsupported products. So on and so forth. Than add namespace support first ! I'm not asking for 'perfect' backward compatibility - it's a difference between removing an xslt liaison for a product that is no longer supported and changing the default behavior on undefined properties. It's a difference between breaking user tasks because they have the same name with an ant task ( which will be a non issue with namespace support), and removing or renaming attributes in chmod or jar or some frequently used task because the old name is not on our taste. > > Ant1 works very well - I haven't had almost any 'itch' with it in almost a > > year. If some functionality requires breaking build.xml and basic task > > patterns - I don't think adding it is the right thing to do. > > thats been made abundently clear. There are however people asking for things > all the time. You can see the same sorts of things being asked for over and > over and over again. Most of these are symptoms of problems in initial design. And most of those things can still be implemented with a minimal impact on what currently work. If someone asks for 'modifiable properties' - that can be done adding a new type of properties with a different syntax, and even recommending and making it the 'official' syntax, or it can be done by just changing the behavior of existing properties to something else. If people ask for exceptions on undefined properties - that can be implemented by using a flag ( or even better, an property ), or by changing the default behavior and screwing all existing projects. Costin -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
