> -----Original Message----- > From: Jon Skeet [mailto:[EMAIL PROTECTED] > Sent: Thursday, 21 February 2002 8:11 PM > To: Ant Developers List > Subject: RE: cvs commit: > jakarta-ant/src/main/org/apache/tools/ant/taskdef s Zip.java > > > > > and is > > > concerned that users will not look kindly > > > upon us getting rid of it. > > > > Changes to task that is exposed to a large group of people > > (which ant1.5 has been) negatively effect users experience of > > ant. I got people bitching at me > > on other lists when ant updated from jarfile -> file, I think > > these people would be even more pissed if that was silently removed > > again ;) > > This seems to be as good a post as any to put my tuppence-worth > in. I'm thinking about Ant2 here - I have no particular views on > 1.5. Obviously there are merits to both sides of the > deprecation/removal/whatever argument: > > (I'm assuming a build-file conversion utility.) > > Leaving stuff in: > o Gives more familiarity for users when it comes to recognising > their converted files and adding to them > o Means we don't need a single preferred name > o Adds to the complexity of the code (in terms of extra methods > which are essentially of no use) > o Adds to the difficulty of reading someone else's build file if > they're using undocumented names > o Keeps existing code which uses varying method calls > > Taking stuff out completely has almost entirely the opposite > effects. Deprecating stuff seems to go half way on almost everything. > > It strikes me that aside from the part about choosing a single > preferred name, a dedicated alias facility in taskdefs would get > round a lot of this. We'd still end up potentially breaking > 3rd-party code, but I suspect this is a given for Ant2 anyway. > I'd like a taskdef to be able to specify aliases for attributes. > The manual could then list those aliases along with the preferred > name, and an optional parameter could tell you if you were using > any aliases instead of preferred names (along with what the > preferred name is). The code could then be cleaned up, and anyone > with a "foreign" build file could easily find out what's going on. >
Good idea. One potential problem, though. One of the problems in Ant 1.x is the fact that once a setter/adder method has been added to a task/type, it cannot be removed because other tasks/types may be directly using it. So, an alias facility would only be feasible if we can prevent that happening in Ant 2 (which I think we should). We can deal with that with a decent antlib versioning/dependency story, or by limiting visibility of types across antlibs. But certainly not do-able in Ant 1. Adam -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
