Why does running tests through jenkins user on build slave fail with Missing scala-library.jar?

Question

I'm trying to run a jenkins job, that fails due to: java.lang.RuntimeException: Missing scala-library.jar When running this line: /usr/lib/jvm/java-1.8.0/bin/java -Xmx4250M -Dsbt.log.noformat=true -jar /tmp/jenkins/slaves/build-slave-cb996aa/tools/org.jvnet.hudson.plugins.SbtPluginBuilder_SbtInstallation/default/bin/sbt-launch.jar 'set credentials += Credentials("Artifactory Realm", $ARTIFACTORY_HOST, $USER, $PASSWORD)' assembly

When running from my own user on the machine or from root, it works fine (fetches the artifacts from jFrog, compiles, runs the tests and packs the jar), but when running from the user jenkins it fails.

I found that when running it from root, it finds the library in the path /root/.cache/coursier/v1/https/repo1.maven.org/maven2/org/scala-lang/scala-library/2.11.11/scala-library-2.11.11.jar

I'm running with sbt.version = 0.13.8 , and scalaVersion := "2.11.11" I obviously don't want the jenkins job to work using root, we all know that's not right. The full stack is:

java.lang.RuntimeException: Missing scala-library.jar
        at scala.sys.package$.error(package.scala:27)
        at sbt.Defaults$$anonfun$scalaInstanceFromUpdate$1$$anonfun$file$1$1.apply(Defaults.scala:382)
        at sbt.Defaults$$anonfun$scalaInstanceFromUpdate$1$$anonfun$file$1$1.apply(Defaults.scala:382)
        at scala.Option.getOrElse(Option.scala:120)
        at sbt.Defaults$$anonfun$scalaInstanceFromUpdate$1.file$1(Defaults.scala:382)
        at sbt.Defaults$$anonfun$scalaInstanceFromUpdate$1.apply(Defaults.scala:384)
        at sbt.Defaults$$anonfun$scalaInstanceFromUpdate$1.apply(Defaults.scala:374)
        at scala.Function1$$anonfun$compose$1.apply(Function1.scala:47)
        at sbt.$tilde$greater$$anonfun$$u2219$1.apply(TypeFunctions.scala:40)
        at sbt.std.Transform$$anon$4.work(System.scala:63)
        at sbt.Execute$$anonfun$submit$1$$anonfun$apply$1.apply(Execute.scala:226)
        at sbt.Execute$$anonfun$submit$1$$anonfun$apply$1.apply(Execute.scala:226)
        at sbt.ErrorHandling$.wideConvert(ErrorHandling.scala:17)
        at sbt.Execute.work(Execute.scala:235)
        at sbt.Execute$$anonfun$submit$1.apply(Execute.scala:226)
        at sbt.Execute$$anonfun$submit$1.apply(Execute.scala:226)
        at sbt.ConcurrentRestrictions$$anon$4$$anonfun$1.apply(ConcurrentRestrictions.scala:159)
        at sbt.CompletionService$$anon$2.call(CompletionService.scala:28)
        at java.util.concurrent.FutureTask.run(FutureTask.java:266)
        at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
        at java.util.concurrent.FutureTask.run(FutureTask.java:266)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
        at java.lang.Thread.run(Thread.java:748)
[error] (*:scalaInstance) Missing scala-library.jar

Thank you!

Centralization

Answer 1

I had a similar problem a couple of weeks ago. If I recall the circumstances correctly, my SBT build utilized the coursier plugin (resulting in a ~/.coursier—%HOME%\.coursier on Windows—directory being created and maintained by the build) and I was also using a local artifact repository (Nexus OSS, in my case).

My problem turned out to be the version of the coursier plugin that my build was using. If you're using coursier v1.0.0-RC2 (or possibly v1.0.0-RC3) or earlier, then this might explain your problem.

The solution was to delete the .coursier and .ivy2 directories (which cache some artifacts locally), change the version of coursier to V1.0.0-RC4 or later, and re-try the build. (In your case, these directories would be on your Jenkins server, in the jenkins account home.)

Neckband

Thank you! I deleted the cache in the server and also moved the coursier from the project/plugins.sbt file : addSbtPlugin("io.get-coursier" % "sbt-coursier" % "1.0.0") to the build.sbt file : libraryDependencies +="io.get-coursier" %% "coursier" % "1.0.1" – Centralization

Answer 2

looks like the library path with root user is pointing to .cache.did you try by clearing the cache.

And also can you try by executing the below command got from

https://github.com/sbt/sbt-assembly

assemblyOption in assembly := (assemblyOption in assembly).value.copy(includeScala = true)

Ebracteate