We have to look into the reason why the shaded version of the compiler
plugin reports the following error and halts the build:
```
protoc-jar: executing: [/tmp/protocjar2818613521400194680/bin/protoc.exe, --plugin=protoc-gen-scala=/tmp/protocbridge4921434211196915044, --scala_out=grpc:/data/rw/code/scala/zinc/internal/zinc-persist/target/scala-2.12/src_managed/main, -I/data/rw/code/scala/zinc/internal/zinc-persist/src/main/protobuf, -I/data/rw/code/scala/zinc/internal/zinc-persist/target/protobuf_external, /data/rw/code/scala/zinc/internal/zinc-persist/src/main/protobuf/schema.proto]
java.lang.AbstractMethodError: Method scalapb/ScalaPbCodeGenerator$.run(Lcom/google/protobuf/compiler/PluginProtos$CodeGeneratorRequest;)Lcom/google/protobuf/compiler/PluginProtos$CodeGeneratorResponse; is abstract
at scalapb.ScalaPbCodeGenerator$.run(ScalaPbCodeGenerator.scala)
at protocbridge.frontend.PluginFrontend$.$anonfun$runWithBytes$1(PluginFrontend.scala:56)
at scala.util.Try$.apply(Try.scala:209)
at protocbridge.frontend.PluginFrontend$.runWithBytes(PluginFrontend.scala:54)
at protocbridge.frontend.PluginFrontend$.runWithInputStream(PluginFrontend.scala:67)
at protocbridge.frontend.PosixPluginFrontend$.$anonfun$prepare$1(PosixPluginFrontend.scala:25)
at scala.runtime.java8.JFunction0$mcV$sp.apply(JFunction0$mcV$sp.java:12)
at scala.concurrent.Future$.$anonfun$apply$1(Future.scala:653)
at scala.util.Success.$anonfun$map$1(Try.scala:251)
at scala.util.Success.map(Try.scala:209)
at scala.concurrent.Future.$anonfun$map$1(Future.scala:287)
at scala.concurrent.impl.Promise.liftedTree1$1(Promise.scala:29)
at scala.concurrent.impl.Promise.$anonfun$transform$1(Promise.scala:29)
at scala.concurrent.impl.CallbackRunnable.run(Promise.scala:60)
at scala.concurrent.impl.ExecutionContextImpl$AdaptedForkJoinTask.exec(ExecutionContextImpl.scala:140)
at java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:289)
at java.util.concurrent.ForkJoinPool$WorkQueue.runTask(ForkJoinPool.java:1056)
at java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1692)
at java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:157)
```
This no longer injects scalaVersion at the project level, which was interfering with crossScalaVersions delegation to ThisBuild scope.
Fixessbt/sbt#3353
Both the default settings and ^^ together sets the correct scalaVersion based on `sbtVersion in pluginCrossBuild`, but frequently people set up `scalaVersion` on sbt plugin's subproject, which disables the feature.
This change appends the scalaVersionSetting on ^^ so scalaVersion gets switched to 2.12.2 on ^^ 1.0.0-RC2 etc.
Fixes#3205
Ref #3282
We used to wrap InputStream so it will inject Thread.sleep, which then allows the thread to be cancelled, emulating a non-blocking readLine. This trick doesn't seem to work for Windows.
For non-Cygwin, actually just removing the wrapping does the job, but I couldn't get it to work for Cygwin.
To test, run some command via network, and then type `show name` into the terminal. On Cygwin, it will not respond.
Calling `.value` on a SettingKey doesn't trigger any execution and
doesn't have any side effect, so we can safely allow calls to `.value`
inside conditionals and lambdas.
Fixes#3299
eugene yokota
Dale Wijnand
Dale Wijnand
jvican
xuwei-k
Martin Duhem