score:0

depending on how complex is the subset of the library that you use, it may be possible to write a wrapper around slick objects that has the interface similar to 2.1.0 (only for things that are actually used) but implemented in terms of 3.0.0. it may be non-trivial and time consuming though.

score:1

afaik this can't be done, because you can only have one version of a dependency in the classpath. even if there was a way to force it, there would be no way to differentiate which version you want when you import.

could be worth looking into osgi as java/maven/etc suffer from the same problem because of how the jvm classloader works.

score:3

having the newer version classes override the older version classes if exists

i believe this is impossible.

what you've encountered is commonly known as "jar hell". the only way i know of to work around it is by using shaded depenedencies (see https://github.com/sbt/sbt-assembly#shading for one example), but that causes other problems.

the cleanest solution (which is unfortunately also the most work) is to just bite the bullet and solve all the issues at once.


Related Query

More Query from same tag