CODEWITHSUNDEEP
scalasbtdependency-management
Amr Kamel
Amr Kamel

Reputation: 432

Scala SBT: Can you import two different versions of the same dependency into one build file?

I need to upgrade one library and there are big breaking changes in the newer version. I was wandering if I can have the two versions imported together somehow using sbt and having the newer version classes override the older version classes if exists. I think that would allow me to do the upgrade gracefully with no compilation errors till I can completely get rid of the older version.

Is this even possible? I can not find anything that says this is possible so far, so if it is not is there a better way to do the migration than replacing the old version with the new version and solve all these errors one bye one?

An example with slick library (results in Unresolved dependencies error)

libraryDependencies ++= Seq(
  "com.typesafe.slick" %% "slick" % "2.1.0",
  "com.typesafe.slick" %% "slick" % "3.0.0"
)

I would appreciate any tips or pointers. Thanks!

Upvotes: 3

Views: 2795

Answers (3)

Denis Makarenko
Denis Makarenko

Reputation: 2938

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.

Upvotes: 0

mbbush
mbbush

Reputation: 182

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.

Upvotes: 3

Matt
Matt

Reputation: 11317

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.

Upvotes: 1

Related Questions