fix scala-xml related regression in 2.11.x-jdk8 build

[SethTisue]

recent 2.11.x-jdk8 builds are failing during Scaladoc generation with "java.lang.ClassNotFoundException: scala.runtime.java8.JFunction1" errors, with scala-xml in the stack traces (example)

it appears that in the context of the community build, the new crossScalaVersions logic in scala/scala-xml@38fbbbe results in scala-xml being built for 2.12.0-M2 instead of for 2.11.8 as intended. (I don't understand why the problem didn't manifest itself earlier, but maybe it did and I'm just forgetful/confused about it.)

I would expect dbuild to override a project's scalaVersion and crossScalaVersions stuff; not sure why that isn't happening here, but I assume it has to do with scala-xml being a scala module. there is a bunch of related-looking stuff in the dbuild manual about dbuild's cross-version setting.

[SethTisue]

full log with dbuild debugging output enabled: https://gist.github.com/SethTisue/e8a9d603c3e597ec1bb9 (run against SethTisue@dcdc747)

[SethTisue]

the problem is not scala-xml specific; it's general to all of the scala modules which are built with the "assemble" build system (because there is a circular dependency between them and scala itself)

and the problem isn't actually completely specific to the 2.11.x-jdk8 build. that's the build where it causes an error, but in the other builds too, the modules are built with the module repo's default scalaVersion, instead of with the Scala that dbuild builds, which is what I expected, given that the whole idea of dbuild is to build everything using a freshly-built Scala compiler

so in the 2.11.x-jdk6 build the modules are built with the stock 2.11.7 compiler, and in the 2.12.x build the modules are built with the stock 2.12.0-M2 compiler. this "works" in the sense that the test pass, but seems like not what we actually want

[SethTisue]

I spent a long time yesterday (and earlier) trying to find the "bug" here, but my current theory is that dbuild is actually working as designed here, so there's no "bug" to be uncovered, it just isn't the design I expected or the design I think we want.

dbuild builds Scala and its modules using the "assemble" build system. the doc on that build system says "the nested projects are built independently, each in isolation", which can be read as describing the behavior in this ticket as intentional. it's not trying and failing to override the module's Scala version — it isn't even trying.

the “assemble” doc also says "designed to provide a transitional compatibility with the initial stages of the Scala 2.11 modularization process. Due to its limitations, and due to the fact that the parts are built independently, it does not offer the same advantages and checks of a standard build file, in which all projects are built on top of one another", which seems like additional confirmation (and comes close to disclaiming that any of this should still work once 2.12 enters the picture)

[SethTisue]

#153 is arguably more of a workaround than a true fix, so keeping this open. a real fix would be to build the module using the Scala we just built, rather than a stock one

[SethTisue]

on second thought, I'll open a new ticket on that

[SethTisue]

superseded by #274