commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Daniel Florey" <>
Subject AW: [proposal] avoiding jar version nightmares
Date Thu, 16 Dec 2004 18:09:54 GMT
In the project that I've been working on, I had to put together some
subprojects into the same ear. As these subprojects interact directly, they
needed to share the same classloader.
They used different versions of httpclient, collections and jdom (this one
caused the most trouble...) and it was hard to figure out, which versions of
each component was in use and how to decompile and refactor the subprojects
to work with the same jars.
As commons components gain more and more attention, more and more commercial
products are using them. It's very common for enterprise applications that
you have to bundle different commercial packages that are not available in
source code. These packages often allow interaction with other packages by
adding some listeners, so it is not possible to deploy them in different
So I think we need a solution for this problem. My proposal would be to
allow different major versions of commons components to coexist. If the
class and package names are equal, this is not possible. My package-version
proposal is just one idea to enable this.


> -----Urspr√ľngliche Nachricht-----
> Von:
> []
> Im Auftrag von David Graham
> Gesendet: Donnerstag, 16. Dezember 2004 18:41
> An: Jakarta Commons Developers List;
> Betreff: Re: [proposal] avoiding jar version nightmares
> I'm still wondering what commons components caused you guys problems in
> your project?  Why should all projects change to renaming packages and
> causing confusion if it's just a few projects that are causing problems?
> My guess is that it's commons collections that is giving you headaches but
> I would like to hear the real world example.
> Thanks,
> David
> --- Oliver Zeigermann <> wrote:
> > On Thu, 16 Dec 2004 09:09:11 -0800 (PST), David Graham
> > <> wrote:
> > > The only time I've seen versioning problems is when commons components
> > > depend on each other and one of them breaks backwards compatibility
> > like
> > > commons collections did recectly.  This is why it's so important for
> > > commons components to have minimal dependencies.
> >
> > Just think of a 1.x version and a 2.x version having the same package
> > and class names, but different method sets or even different
> > semantics. Now in a large project a piece of software from one vendor
> > needs 1.x and another one needs 2.x. Now consider they really need to
> > share the same class loader and you are lost. You would not if you
> > could have both 1.x and 2.x usable at the same time. Daniel's proposal
> > would make this possible.
> >
> > Oliver
> >
> > Disclaimer: Daniel talked this over with me in person yesterday, so
> > our points of view are pretty much aligned.
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail:
> > For additional commands, e-mail:
> >
> >
> __________________________________________________
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam protection around
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message