commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Eric Pugh" <ep...@upstate.com>
Subject RE: AW: AW: AW: [proposal] avoiding jar version nightmares
Date Tue, 21 Dec 2004 17:58:46 GMT
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:craigmcc@gmail.com]
> Sent: Sunday, December 19, 2004 5:28 PM
> To: Jakarta Commons Developers List; ozeigermann@apache.org
> Subject: Re: AW: AW: AW: [proposal] avoiding jar version nightmares
>
>
> On Sun, 19 Dec 2004 23:25:30 +0100, Oliver Zeigermann
> <oliver.zeigermann@gmail.com> wrote:
> > On Sun, 19 Dec 2004 22:17:10 -0000, Stephen Colebourne
> > <scolebourne@btopenworld.com> 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: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message