NoClassDefFoundError: scoverage/Invoker$

[YannMoisan]

scoverage 1.1.0
sbt : 0.13.8

I've encountered the following error :

[info] Exception encountered when attempting to run a suite with class name: xxx *** ABORTED *** (714 milliseconds)
[info]   java.lang.NoClassDefFoundError: scoverage/Invoker$

It's a multiproject build and this issue happens only on one subproject…

[YannMoisan]

Disabling the gatling plugin make it work. Is there known incompatibility ?

[XinyuHua]

From http://d.hatena.ne.jp/lranran123/20150423/1429754799
How about adding libraryDependencies ++= Seq("org.scoverage" %% "scalac-scoverage-runtime" % "1.0.4") to your build.sbt?

[killercentury]

Have a similar issue when I use a Docker image that built with sbt docker:stage

Exception in thread "main" java.lang.NoClassDefFoundError: scoverage/Invoker$
    at modules.SilhouetteModule.configure(SilhouetteModule.scala:41)
    at com.google.inject.AbstractModule.configure(AbstractModule.java:62)
    at com.google.inject.spi.Elements$RecordingBinder.install(Elements.java:340)
    at com.google.inject.spi.Elements.getElements(Elements.java:110)
    at com.google.inject.util.Modules$OverrideModule.configure(Modules.java:177)
    at com.google.inject.AbstractModule.configure(AbstractModule.java:62)
    at com.google.inject.spi.Elements$RecordingBinder.install(Elements.java:340)
    at com.google.inject.spi.Elements.getElements(Elements.java:110)
    at com.google.inject.internal.InjectorShell$Builder.build(InjectorShell.java:138)
    at com.google.inject.internal.InternalInjectorCreator.build(InternalInjectorCreator.java:104)
    at com.google.inject.Guice.createInjector(Guice.java:96)
    at com.google.inject.Guice.createInjector(Guice.java:73)
    at com.google.inject.Guice.createInjector(Guice.java:62)
    at play.api.inject.guice.GuiceBuilder.injector(GuiceInjectorBuilder.scala:126)
    at play.api.inject.guice.GuiceApplicationBuilder.build(GuiceApplicationBuilder.scala:93)
    at play.api.inject.guice.GuiceApplicationLoader.load(GuiceApplicationLoader.scala:21)
    at play.core.server.ProdServerStart$.start(ProdServerStart.scala:52)
    at play.core.server.ProdServerStart$.main(ProdServerStart.scala:27)
    at play.core.server.ProdServerStart.main(ProdServerStart.scala)
Caused by: java.lang.ClassNotFoundException: scoverage.Invoker$
    at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
    at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
    at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:331)
    at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
    ... 19 more

[sksamuel]

It sounds like something else is fiddling with the classpaths of the compiler. If it can't find scoverage.Invoker$ then it means the runtime.jar isn't being passed to the source. Are there other plugins at play here?

[ndjido]

Hi all,
I'm experiencing the same issue and the libraryDependencies ++= Seq("org.scoverage" %% "scalac-scoverage-runtime" % "1.0.4") trick does not fix the problem.

[ndjido]

Setting "coverageEnabled.in(Test, test) := true" in my build.sbt file saves my day !

[RichardBradley]

It's a multiproject build and this issue happens only on one subproject…

Does version 1.3.1 fix this? See #87

[kevinmeredith]

I updated from:

addSbtPlugin("org.scoverage" % "sbt-scoverage" % "1.1.0")

to 1.3.3. Then, I no longer saw this problem.

[kevinmeredith]

Actually, I take back what I said. I'm still seeing this error at run-time.

[RichardBradley]

Do you have a repro we can try?

[hibikir]

I have access to Kevin's project. It's a service, using a library that has sbt coverage in its plugins. It tests just fine, but the jar that it ends up building, and that then we release, still has the instrumentation on it. So whenever it's used in a situation that doesn't include the plugin (for instance, at run time of the service), then the classes fail to load, as they all want to still report their coverage to the plugin.

So now the question is to figure out how in the world do the output jars in /target, which other plugins will use to cut a release, end up having the coverage instrumentation still in them.

[RichardBradley]

So now the question is to figure out how in the world do the output jars in /target, which other plugins will use to cut a release, end up having the coverage instrumentation still in them.

scoverage used to put the instrumented classes in target/scala-x/scoverage-classes, but a few months ago it was changed to instrument the main output dir of target/scala-x/classes. (I guess because there were recurrent bugs caused by the different output dirs.)

I think that means that you now need to do a "sbt clean" after any scoverage testing before running anything like "sbt package", or you risk packaging up instrumented classes, as you have found.

If that is the case, it should be easy to create an isolated repro case.

I'm not sure what the fix would be. It does seem like putting the instrumented classes in a separate dir would avoid lots of niggling and hard to anticipate bugs like this one, but obviously @sksamuel changed that for a reason (my guess is lots of niggling and hard to track down bugs). @sksamuel ?

I don't have much time to repro or fix this at the moment, but hopefully this will help. Try a "sbt clean" as a workaround?

[rowlandwatkins]

Hi folks,

Forcing scala-scoverage-runtime >= 1.1.0 fixes this issue when defining custom test environments (unit tests run fine). sbt clean in all instances did not help, neither did wholesale deletion of target.

Cheers,

Rowland

[alexland]

remember that tasks in sbt can be name-spaced; so eg, using one of the pre-built configurations provided by sbt (Test), works for me:

coverageEnabled in Test := true

and given this, i'm not so sure this Issue is a bug; (Tasks & Settings) key namespaces (aka configurations) are an essential part of sbt architecture. What's more the auto-plugin interface for building sbt plugins (as far as i can tell) doesn't really have an organic/native way to implement context-specific behavior (of the plug-in)--so it seems the sbt devs decided to delegate this to the user and provided the configurations api for this purpose. (The other template configurations supplied by sbt, along with Test, are Compile, Runtime, and IntegrationTest.)

[ottovw]

if this is not treated as a bug, which is reasonable after reading @alexland description. one should create a logger warning telling the user to configure correctly and update documentation.

however, i would prefer "fixing" the actual problem

[mmacfadden]

I am not sure if I am having a related issue or not. The issue I am having is essentially described here:

http://stackoverflow.com/questions/30262119/noclassdeffounderror-running-tests-in-sbt-with-scoverage-plugin

The main issue is that I am running tests in a custom configuration. when I turn coverage on in the multi-project built running "test" works for all projects. When running e2e:test I get the infamous:

Cause: java.lang.ClassNotFoundException: scoverage.Invoker$
[info] at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
[info] at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
[info] at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:331)
[info] at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
...

exception. It seems that the test code is getting instrumented, but that the dependencies are not there when running the tests. Is this related or perhaps a separate issue?

[jan0sch]

Hi,

we're experiencing this problem since yesterday on all our machines but one. We first thought this was brought down upon us by updating sbt-scoverage form 1.3.3 to 1.3.5 but a downgrade didn't solve the error.

If we run sbt test with the plugin enabled we get an error message like this on several (not all) tests:

java.io.FileNotFoundException: PROJECT-PATH/target/scala-2.11/scoverage-data/scoverage.measurements.60 (No such file or directory)

If we disable the scoverage plugin by either config or also by removing the dependency then we get the following error on several tests:

java.lang.NoClassDefFoundError: scoverage/Invoker$

This is extremely confusing because if I remove the plugin from the project and run sbt clean shouldn't it be gone?

Can anyone shed some light on this?

[jan0sch]

I was able to solve the NoClassDefFoundError after removing sbt-scoverage. We were using some libraries that are also using sbt-scoverage and therefore they shipped with the instrumented code that would produce errors if scoverage-runtime was not in the classpath.

This seems to relate to #153 and #128. I would consider them high priority issues. We've currently removed scoverage from our projects because there seems to be now way right now to not pollute the produced binaries. As a workaround our CI server adds the plugin via script and executes the coverage tasks to produce the desired reports.

[adrianovinhas-zz]

Hi guys,

I was having the same problem:
java.lang.NoClassDefFoundError: scoverage/Invoker$

I read through this thread and added sCoverage to my dependencies in build.sbt (v 1.1.0).

To provide some context, I'm building my project on Jenkins and then ssh-ing the target to a different machine, and I'm trying to run it from that machine. After this point I got a new error:
Exception in thread "main" java.io.FileNotFoundException: /var/lib/jenkins/jobs/ project/workspace/target/scala-2.11/scoverage-data/scoverage.measurements.1

It seems that I would need some file that is not included by the command activator dist while that file in fact on the machine that is running Jenkins.

My solution is a quite ad-hoc solution, but I decided to post it here hoping that in can help some of you. What I did was to first run my tests, and then dist with the coverageOff. This way, files in your target won't depend on anything related with sCoverage and you will be able to run them.

activator clean test
activator coverageOff dist

[rogue-one]

setting this fixed the problem for me coverageEnabled.in(ThisBuild ,Test, test) := true
my version is 1.3.5

[jan0sch]

@mig-foxbat Thanks for the hint.

[adamosloizou]

+1 for the issue.
In our project we overwrite the it configuration with a custom configuration for our integration tests that extends Test:

lazy val MyIntegrationTest = config("it") extend Test
lazy val itSettings: Seq[Setting[_]] = inConfig(MyIntegrationTest)(sbt.Defaults.testSettings)
parallelExecution in MyIntegrationTest := false

I've tried all of the suggestions above including:
Presetting it:

coverageEnabled in Test := true
coverageEnabled in MyIntegrationTest := true

Writing a command that adds the status to the scope it exactly like in the plugin:

commands += Command.single("enableCoverage"){ (state, trueOrFalse) =>
  val extracted = Project.extract(state)
  val newSettings = extracted.structure.allProjectRefs flatMap { proj =>
    import ScoverageSbtPlugin._
    println("here it is:" + trueOrFalse.toBoolean)
    Seq(
      coverageEnabled in proj := true,
      coverageEnabled in (proj, Test, test) := true,
      coverageEnabled in (proj, MyIntegrationTest, test) := true,
      libraryDependencies in proj ++= {
        if (trueOrFalse.toBoolean) Seq(
          OrgScoverage % (ScalacRuntimeArtifact + "_" + scalaBinaryVersion.value) % DefaultScoverageVersion % "provided" intransitive(),
          OrgScoverage % (ScalacPluginArtifact + "_" + scalaBinaryVersion.value) % DefaultScoverageVersion % "provided" intransitive()
        ) else Nil
      }
    )
  }
  extracted.append(newSettings, state)
}

Unfortunately I still get the exception for my integration tests.
Any ideas?

[hex337]

I also seem to also have this issue when trying to use it on a custom defined test configuration:

lazy val funTest = config("ft") extend (Test)

coverageEnabled in Test := true
coverageEnabled in funTest := true

It works for my unit tests, but not my functional tests.

[softprops]

Observing this as well. Putting coverageEnabled in the Test scope seems to remove all coverage instrumentation when I run my unit tests

[rgarciate]

Hello.
I only added "addSbtPlugin("org.scoverage" % "sbt-scoverage" % "1.3.5")" to my plugins.stb file (I don't have coverageEnabled or anything, just that line at plugins.sbt) and I've been experiencing this problem for the last two days when I run my application this way:
";clean;coverage;test;docker:publish;coverageReport;coverageAggregate"

Today, I just add coverageOff after 'test' word, staying as follows: ";clean;coverage;test;coverageOff;docker:publish;coverageReport;coverageAggregate"
And it works properly, maybe my solution will work for anyone.

Cheers, Roberto

[olix0r]

I was able to resolve this by explicitly adding the scalac-scoverage dependencies to my other test configuration:

.settings(libraryDependencies += "org.scoverage" %% "scalac-scoverage-runtime" % "1.1.1" % EndToEndTest)

[stanch]

I also experienced this issue on a subproject where the Gatling plugin was enabled. I noticed that the coverage was running the gatling:test task instead of test:test. This change solved the problem:

- addCommandAlias("testCoverage", "; clean; coverage; test; coverageOff; coverageReport; coverageAggregate")
+ addCommandAlias("testCoverage", "; clean; coverage; test:test; coverageOff; coverageReport; coverageAggregate")

[theRolandDeschain]

Adding coverageOff after test in my addCommandAlias in build.sbt fixed this issue for me as well
";clean;compile;coverage;test;coverageOff;coverageReport"

[mziemba]

";coverage;test;coverageOff;coverageReport;coverageAggregate" works for me as well in a multi-module build (using plugin version 1.3.5). If this is how it is supposed to be done, it should be documented somewhere.

[serhiip]

Had the same issue for Scala.js sub-project. The only way I was able to fix it is by redefining libraryDependencies with org.coverage package filtering - https://github.com/serhiip/jobsscan/blob/a9f371782f8f3b127f2335dc796bc50b480de209/build.sbt#L28.

I am really curious if this is a known issue or sbt-coverage considered fixed for Scala.js and should be working just fine?

[ghost]

@serhiip Your's is a new usage query, please could you ask this on stackoverflow?

This old issue should now be closed.

[gslowikowski]

Yes, this issue is a can of different issues. All of then should be fixed now. If similar problems arise, please open new issues.

@serhiip, if you open new issue (here on on stackoverflow), write how to reproduce your issue (what tasks to execute).

[geula]

1.6.8 seems to be broken again, I downgraded to 1.3.3.

[bruckwubete]

try running sbt clean and try again. That fixed it for me.