fix scala-xml related regression in 2.11.x-jdk8 build about community-build HOT 6 CLOSED

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

from community-build.

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

from community-build.

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)

from community-build.

#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

from community-build.

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

from community-build.

superseded by #274

from community-build.