I have to jump into this as well. I hope I am not just repeating what wiser minds have already said :-). The idea of changing package names just seems like a solution that looks simple, but will rapidly become a nightmare. As far as I know, no other set of libraries follow this pattern, including the Java libraries, and I think this suggests that doing this isn't wise.
And, in my experience watching work done with tools like Gump, any time people do weird trickery with package names, like Sun renaming some packages from x.y.z to com.sun.x.y.z, this inevitably seems to cause lots of problems somewhere down the line. Additionally, people will soon start writing tools similar to commons-logging that attempt to put a facade over all the versions so you don't have to know which version you are working with. I understand why it is a problem, but it seems like a better solution is to pressure app vendors to upgrade faster (by using tools like Gump that demonstrate the newer versions are solid against many packages) as well as implement classloader isolation. Eric > -----Original Message----- > From: Craig McClanahan [mailto:[EMAIL PROTECTED] > Sent: Sunday, December 19, 2004 5:28 PM > To: Jakarta Commons Developers List; [EMAIL PROTECTED] > Subject: Re: AW: AW: AW: [proposal] avoiding jar version nightmares > > > On Sun, 19 Dec 2004 23:25:30 +0100, Oliver Zeigermann > <[EMAIL PROTECTED]> wrote: > > On Sun, 19 Dec 2004 22:17:10 -0000, Stephen Colebourne > > <[EMAIL PROTECTED]> wrote: > > > I would also -1. Versioned packages is not an acceptable solution. > > > > What is an acceptable solution then? > > Do what I said already ... create subordinate class loaders *within* > your application, and load the offending subordinate modules into > their own class loaders, with their own dependencies. > > > > > Oliver > > > > Craig > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
