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