How to handle dependencies on multiple versions of the same library?

[Andy Fingerhut]

I haven't actually run across this before, but I suspect someone else has. I was curious how people handle it.

Suppose you have your project A, and it uses Leiningen (the issue is more widely applicable, but for the sake of example).

* A depends on some version of library B, which in turn depends on library Z version 2
* A also depends on some version of library C, which in turn depends on library Z version 3

Simple case 1: B also works with Z v3, so update its dependency, use Z v3, and everything works. (similarly easy if Z v2 works for C)

Hard case: B only works with Z v2, and C only works with Z v3.

Is there a straightforward way to load in both versions of Z to a single JVM, and make everything work?

Perhaps this is the kind of situation that Gradle, OSGi, and probably other tools/frameworks are meant to help address?

Thanks,
Andy

[kurtharriger]

OSGI is one way to solve this problem, but it is rarely worth the effort. It requires adding lots of meta data to every dependency which only a few major libraries actually provide. There are some tools to help with this process but they dont generally work with dynamic languages. Honestly, unless you know someone that has significant experience with OSGi, you will spend far more time trying to get everything working under OSGi than it would take to update the library with the old dependency to work with the latest version of the shared dependency - providing of course the source is available, and one of the reasons I avoid closed source libraries whenever possible. Even still running multiple versions of the same jar in osgi is still not ideal and can cause other issues. You can also implement you own classloaders, which is basically how OSGi is implemented, but much less painful then OSGi.

Gradle is just a build tool, it will basically just select the newest version of the shared dependency. It will not help them coexist.

If updating the library is not an option or to overwelming, then the next best thing is to create a seperate application for the old library and use ipc of some sort such as a rest api to allow the libraries to collaberate yet live in separate jvms.

[Tassilo Horn]

Andy Fingerhut <andy.fi...@gmail.com> writes:

Hi Andy,

> I haven't actually run across this before, but I suspect someone else
> has. I was curious how people handle it.
>
> Suppose you have your project A, and it uses Leiningen (the issue is
> more widely applicable, but for the sake of example).
>
> * A depends on some version of library B, which in turn depends on
> library Z version 2
> * A also depends on some version of library C, which in turn depends
> on library Z version 3

I ran into that issue, where library Z was actually clojure itself in
versions 1.2.0 and 1.3.0 (and my own lib wanted 1.4.0-betaX).

The solution was to use Leiningen's :exclusions keyword.

:dependencies [[org.clojure/clojure "1.4.0"]
[foobar "1.1.0" :exclusions [org.clojure/clojure]]
...]

That means, depend on the foobar lib 1.1.0, but ignore its clojure deps.

Of course, that only works, if foobar is compatible with clojure 1.4.0
but just doesn't manifest that in its :dependency spec.

Bye,
Tassilo