4

I need to add a .jar as an unmanaged dependency to an sbt Scala project (it is the java-stellar-sdk). Everything works well as long as I don't run sbt test. There seems to be a Mockito version in the .jar file that conflicts with the one I am using in the project. I get a lot of errors that certain Mockito matchers are not found but everything works fine without the .jar in the lib folder.

Is there a way to tell sbt that it should ignore certain libraries in the .jar or that managed dependencies take precedence? I also found this related question but obviously it didn't help me.

An alternative workaround would also help a lot. Is it possible to isolate the libraries in the jar in a way that allows me to just make a certain package visible to the outside?

Update: The .jar contains Mockito 2 but my project uses Mockito 1, so this is a very simple and obvious conflict, that I can solve by upgrading to Mockito 2 (which I tried and it works). However, the question remains: Is there another reasonable way to isolate the Mockito dependency in the .jar to not interfere with my project in case I can't or don't want to resolve the conflict buy switching to a newer version of the library in question. Maybe altering the .jar to rename the conflicting packages? I don't know. Something like that.

I know that this is a very general question that has likely been discussed somewhere else in depth. However, I didn't find anything that really satisfied me. Links to relevant discussions of the topic are of course appreciated as well.

lex82
  • 11,173
  • 2
  • 44
  • 69
  • If you are offering a bounty for that, you should probably at least provide the relevant snippets of the `build.sbt`. Otherwise, it looks more like a pretty vague statement that "there is some jar-hell somewhere". – Andrey Tyukin Mar 10 '18 at 20:46
  • @AndreyTyukin, I updated the question and tried to make it clear what I am asking for. – lex82 Mar 10 '18 at 22:19
  • can you post the build.sbt contents? – Akash Tantri Mar 12 '18 at 11:19
  • @AkashTantri, I extended the question to explain why the build.sbt is not relevant. I'm not asking how to solve my particular problem (which I did already) but it is a general question. – lex82 Mar 12 '18 at 15:18

2 Answers2

3

I can think of 3 ways for you to do it (ordered from simple to difficult):

  1. delete mockito 2 manually from the jar file.
    Since the jar is just a zip file, you can extract it, delete all the conflicting files, and pack it again.

  2. compile that jar from source by yourself, and set mockito as a test dependency (as it should be). If you do that, consider opening a PR with your change, to fix the problem for the community

  3. Shade the mockito files in the jar.
    shading is the process of renaming all files in a jar file by certain rules. you can either use jarjarlinks or with sbt assembly plugin. see this answer to get you started with sbt assembly: https://stackoverflow.com/a/47974750/245024
lev
  • 3,986
  • 4
  • 33
  • 46
1

You should be able to arrange for your Mockito 1 classes to appear before the Mockito 2 classes on the classpath. That will cause your classes to win any conflicts.

Rich
  • 15,048
  • 2
  • 66
  • 119
  • Ok, how do I do that? The Mockito 2 classes are in a .jar file in the lib folder. The Mockito 1 dependency is in the sbt file. – lex82 Mar 13 '18 at 12:47