NoSuchMethodError for scala 2.12.13

[aaabramov]

Error: java.lang.NoSuchMethodError: scala.tools.nsc.Global.reporter()Lscala/tools/nsc/reporters/Reporter

Reference and all details: sbt/sbt#6251

Error: https://github.com/bitcoin-s/bitcoin-s/pull/2509/checks (credits to sbt/sbt#6251 (comment) / @Christewart)

[eed3si9n]

Unlike scala-library, there's no binary compatibility guarantees between two patch releases of scala-compiler. Thus well-designed compiler plugins are released with

    crossVersion := CrossVersion.full,
    crossTarget := target.value / s"scala-${scalaVersion.value}",

However, sbt-scoverage seems to be using %%, which is suspicious:

sbt-scoverage/src/main/scala/scoverage/ScoverageSbtPlugin.scala

Lines 55 to 65 in ddec737

	libraryDependencies ++= {
	if (coverageEnabled.value)
	Seq(
	// We only add for "compile"" because of macros. This setting could be optimed to just "test" if the handling
	// of macro coverage was improved.
	OrgScoverage %% (scalacRuntime(libraryDependencies.value)) % coverageScalacPluginVersion.value,
	// We don't want to instrument the test code itself, nor add to a pom when published with coverage enabled.
	OrgScoverage %% ScalacPluginArtifact % coverageScalacPluginVersion.value % ScoveragePluginConfig.name
	)
	else
	Nil

In the case of Scala 2.12.13, binary compatibility was intentionally broken in scala/scala#9300.

[solarmosaic-kflorence]

Any idea when this will be fixed? Considering disabling scoverage as we need to upgrade to 2.12.13 for other reasons.

[blast-hardcheese]

I'm giving a PR a shot. Starting from Eugine's comment from earlier, I presume %%% is the way to go, but I've not worked with the portable-scala infrastructure before, so we'll see how far I get.

[SethTisue]

@D-Roch @gslowikowski are you guys around to merge a PR, if one was submitted...?

[0xRoch]

@SethTisue I can do it

[jimm-porch]

Bonus request - It would be sweet if the scoverage homepage had a table listing all supported versions. Scala devs are so used to major-version compatibility that it is very surprising when a library only supports specific minor versions, and it would save some time if they were explicitly called out in the README.

[blast-hardcheese]

Status update: I failed at my initial attempts -- I'll give another shot at it next week. The particular way the runtime is depended on seems less inclined to be compatible with %%% all my attempts to get it working with local publishing have failed so far.

[eed3si9n]

Sorry I meant that instead of %%,.cross(CrossVersion.full) should be used like ("org.typelevel" % "kind-projector" % "0.11.3").cross(CrossVersion.full).

[blast-hardcheese]

@eed3si9n Totally missed that -- I thought it was similar to how scalajs worked. Thanks!

[blast-hardcheese]

That was the trick. Gonna clean up a source compatibility issue between different versions of scalac then open the PRs

[blast-hardcheese]

OK. That should do it.

[blast-hardcheese]

This is still an issue, it got automatically closed.

• Build CrossVersion.full scalac-scoverage-plugin#306 needs to be merged and released
• https://github.com/scoverage/sbt-scoverage/blob/master/src/main/scala/scoverage/ScoverageSbtPlugin.scala#L14 needs to be bumped to the new version
• then sbt-scoverage needs to be released

[blast-hardcheese]

@D-Roch Is there something else required in order to release scalac-scoverage-plugin? I can open the follow-up PR to bump the version in sbt-scoverage so we can resolve this

[zantekk-dev]

@D-Roch @blast-hardcheese Do we have a rough ETA on when this will be completed / released?

[blast-hardcheese]

@D-Roch indicates he's busy, @gslowikowski may be around to release scalac-scoverage-plugin, which is what's blocking us now.

If there's a need to widen the maintainer group if the current maintainers aren't available to keep things moving, this could also be a discussion worth having. Additionally, if a company is willing or interested in funding this project, presumably that would be welcome (again, depending on the desires of the current maintainers).

(Of course, I mean no disrespect by the above observation, but this changeset explicitly requires a new release every time a patch release of the compiler is cut, which will increase the maintenance burden. I think calling this out is important, while there are so many eyes on this issue)

[mcanlas]

Are there any updates on how this issue will be fixed? Are the current maintainers available to release an update or widen the group?

[ghost]

The issue is closed and the release hasn't been made yet. Is there any other ticket to track progress on the release?

[fehu]

@niyassait
#321