> > 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. Apologies if this is an idea with grave flaws in or which has been brought up before. Jon
