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
This is modification of crash log event logging that was added in sbt/util#85.
Instead of using the hardcoded 0 as the default value, this introduces `setTrace(..)` to `ConsoleAppender` like `BasicLogger`. Also the default value is set to `Int.MaxValue` that will display the full stack trace.
Fixessbt/sbt#3343
Fixes sbt/sbt#3348
Ref #101
The new logger, based on log4j separates the concern of the log producer (Logger) and the handlers that takes actions (Appender, e.g for displaying on Console). As such filtering of color should be performed only in the ConsoleAppender.
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