The reported issue was a JLine class not being found on sbt startup.
JLine was depended on in the sbt build in two places, one with an extra
attribute (component) and one without. The retrieve pattern used by the
launcher includes that extra attribute. Previously, the dependency
without the attribute was selected and jline properly ended up on the sbt
classpath. Now, either by bumping JLine to 2.11 or some other
insignificant change, jline ends up in a subdirectory for the component
and doesn't get on the classpath.
(The move in 0.10 away from retrieving based on patterns and
using things directly from the cache was good, but this can't be
used in the launcher until a hash-based artifact is used so that
sbt+Scala jars aren't deleted or overwritten while sbt runs.)
A secondary issue was that the compiler-interface-src artifact didn't have
a configuration and was therefore not included in the published artifacts.
It is no longer necessary for it to be loaded in a stable class loader
and line reading in the launcher does not require anything more advanced
than java.io.Console.readLine(String).
Scala versions 2.8 and later use the version that goes through JAnsi
and for that it is sufficient to have JNA in a stable loader.
Needed an explicit type in PMap to workaround an error.
Need to drop tuple assignment of parser.parsed in input task macro as a workaround
for macro/resetAllAttrs/pattern matching/annotation issue in RC1.
Silencing boring warnings allows seeing the interesting ones. Here I've excluded
reflectiveCalls, since that's a useful warning.
However, silencing those warnings in *Eclipse* would require committing Eclipse
projects, something which *will* take extra effort; I verified that the warnings
disappeared from the output of compilation in SBT.
All of `sbtVersion`, `defScalaVersion` and `buildScalaVersions` were
not used anymore. According to @harrah they are coming from really
old days of sbt and are not needed because of changes to how sbt
interacts with different Scala versions.