No deps

[ghost]

M0 version, no scala-js but should be OK to build scalac and some compiler plugins

[gslowikowski]

Introduction

This is short summary of our Gitter discussions.

The original goal was to be able to add scoverage to Scala build. Additional goals (added later):

• add scoverage build to Scala community builds,
• to be able to add scoverage to the builds of some compiler plugins,
• separate reporting functionality from compiler plugin code (into new module).

Technically it means:

• need for pure Java scoverage runtime to be used in Scala build instead of our current, Scala dependent ones,
• ability to build scoverage plugin for any Scala version available, any means: any published, e.g. 2.12.0-RC1-1e81a09 or current snapshot (e.g. in Scala build or in Scala community builds)
• ability to publish to Maven Central repository scoverage plugin (and Scala runtime?) for any Scala version

Ability to build scoverage plugin for any Scala version available means we need to:

• replace current ScalaJS CrossProject with pure Scala one, like it was before SJS support introduction and ScalaJS dependent on into separate repo,
• remove ScalaTest test dependencies here, here and here by rewriting tests in JUnit
• remove Scala Logging test dependencies here and here and use some other way to test macro-related functionalities: test1 and test2.

If I forgot something let me know.

This PR review

General notes

• I would like minimize changes in scalac-scoverage-plugin repo to avoid git history losing (check my proposal),
• the idea of additional repository started from the need to extract Java runtime from scalac-scoverage-plugin but now plugin and Scala runtime modules were moved from there too, this is not necessary
• cross compiling plugin for full Scala version - maybe it's required, maybe not. It causes additional problem during release/publishing - we will have to release new version of Scoverage plugin for every new Scala version (described below),

Pure Java runtime

• instead of one, Scala independent library, we have one module for every Scala version used. Everyone has scala-library dependency. This is wrong. Scala independent module must be written in pure Java with crossPaths := false and autoScalaLibrary := false. I've created example implementation,
• there is no need to change name from scalac-scoverage-runtime to scalac-scoverage-runtime-java,
• after making it Scala independent this module must be moved to separate repository because during publishing/release process SBT would try to (re)publish it for every Scala version which leads to exception (somewhere inside Ivy).

Scala runtime

• there is no need to move it from scalac-scoverage-plugin repository. This runtime project is now ScalaJS dependent. It must be split into two separate projects: one ScalaJS-independent is this one, but there is no need to move it here from scalac-scoverage-plugin repository (we lose git history); it should stay there and should look like it was before SJS integration and one ScalaJS-dependent, which needs separate repository because it cannot be built for any Scala version, but only for the ones supported by ScalaJS. I've prepared example implementation,
• there is no need to change name from scalac-scoverage-runtime to scalac-scoverage-runtime-scala

Plugin

• there is no need to move it from scalac-scoverage-plugin repository and losing git history,
• plugin tests shouldn't be moved to runtimes, they're plugin tests, not runtime; there is no need to test plugin with all available runtimes (what about the ones in seperate repos, like sjs runtime ?),
• plugin module with CrossVersion.full being part on multimodule project causes problems with publishing plugin version for specific Scala version (sbt ++scalaVersion publish); e.g. if after releasing version 2.0.0-M0 we want to publish plugin version for Scala 2.11.9 when it will be released, we could checkout v2.0.0-M0 tag and run sbt ++2.11.9 publish, but it will not work because SBT will try to publish all modules and runtime modules with _2.11 name suffixes are already present in Maven central repository; the only way is to release new version of Scoverage - not good
• what about macro testing after scala-logging test dependency removal? one macro test was removed from PluginASTSupportTest class and one macro and one other test were commented in PluginCoverageTest class

Publishing problems

Lets say, our starting point is 2.0.0-M0 release with runtimes for: 2.10.6, 2.11.8 and 2.12.0-RC2 and plugin for : 2.10.6, 2.11.8, 2.12.0-M3, 2.12.0-M4, 2.12.0-M5, 2.12.0-RC1-ceaf419, 2.12.0-RC1, 2.12.0-RC1-1e81a09 and 2.12.0-RC2 (as in build.sbt file)

What will we do, when new stable Scala version (e.g. 2.11.9) gets released? There are two possibilities:

• add it to our build.sbt and release new version (e.g. 2.0.0-M1),
• publish 2.0.0-M0 for that Scala version, but it's not possible. It would require to checkout v2.0.0-M0 tag and run sbt ++2.11.9 publish. It will not work because SBT will try to publish all build modules: scalac-scoverage-plugin_2.11.9, scalac-scoverage-runtime-scala_2.11 and scalac-scoverage-runtime-java_2.11, but these two runtime artifacts are already present in Maven central repository. The same version published many times for different Scala versions.

So we need to release new Scalac Scoverage plugin version for every new stable Scala version. I don't like it. For example look, how scala-xml 1.0.5 was published - version for Scala 2.11 was published on 24-Jul-2015, version for Scala 2.12.0-RC1 was published on 06-Sep-2016 and version for Scala 2.12.0-RC2 was published on 14-Oct-2016

PS

I tried to work concurrently with @BennyHill and ended with different solution. My example repos are:

• scalac-scoverage-plugin,
• scalac-scoverage-runtime-java,
• scalac-scoverage-runtime-sjs06,
• sbt-scoverage.

This is only my proposal, how to split code differently, better IMO. The tests were not rewritten from ScalaTest to JUnit because I didn't want to duplicate @BennyHill's work. Plugin module was split into plugin and report modules quickly, without analyzing details, so @BennyHill for sure did it better.

[gslowikowski]

What shall we do with this PR?