This is a major "broken window", IMHO, and it should be fixed. Why not leave the API the way it is and just take out the classes that are duplicated? They are in the same packages as are in the commons-collections jar file. I understand that it causes a dependency on commons collections (which is big), but at least the user knows what exactly they're getting rather than playing classloader bingo. Also, the dependency is a conditional one. You only need collections if you're using these specific classes. There are probably not too many users of these classes anyway. I would venture to say that there are probably not too many projects using beanutils that aren't using collections anyway (once you start playing with commons libraries, you can't stop; they're addictive).
On 5/19/07, Stephen Colebourne <[EMAIL PROTECTED]> wrote:
Torsten Curdt wrote: > On 18.05.2007, at 21:56, Thorbjørn Ravn Andersen wrote: >> I suggest marking the offending methods as deprecated for the 1.x >> series, and schedule them for removal in the 2.x series. > > Well, then let's create a 2.x branch and do a release without the > classes *now*. No problem with that. Then it is communicated and people > can choose. But doing *nothing* just because of binary compatibility is > silly. Doing nothing because of binary incompatibility is not silly, its essential. Commons has to be far more extreme than almost any other OSS project on this point. In fact, I contend that commons is now in such a position that we can't make incompatible changes even in major version number releases. > Especially as no one *has* to upgrade libraries. And checking > release notes if you do can't hurt if you upgrade. Users are forced to upgrade all the time, and thats why they require backwards compatibility. For example, if project A is complied against the old [beanutils] jar, while project B is compiled against the new [beanutils] jar, then it is impossible to use both project A and project B together. You cannot physically upgrade the jar file to the one B needs, because A needs the old one. The only solutions to this at present are - for the 2.x series to have a different package name, including 'v2' - to force the user to play with class loaders, so they can load two different versions of the same class In summary, I suggest we all just let this one be. This isn't causing major pain IMO. The lesson should be to not have dependencies between commons projects wherever possible. Stephen --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
