Paul Draper
Paul Draper
> scalac expects each plugin to be fully isolated, so we need to smash everything together with singlejar Really? This contradicts https://github.com/sbt/sbt/issues/2255 which claims that the entire plugin classpath is...
There are used [here](https://github.com/higherkindness/rules_scala/blob/master/src/main/scala/higherkindness/rules_scala/workers/zinc/compile/ZincRunner.scala#L221-L230). I think they make incremental compilation work more effectively if it is enabled. You could ask on the [Zinc Gitter](https://gitter.im/sbt/zinc-contrib). I am not certain they are...
Odd. It appears that it intends to support workers. https://github.com/bazelbuild/bazel/blob/master/src/java_tools/singlejar/java/com/google/devtools/build/singlejar/SingleJar.java
The intention always was to *ideally* merge back with rules_scala. rules_scala was difficult to work with (technically and otherwise) and innovate, so this was a proving grounds for a better...
The error comes from [here](https://github.com/higherkindness/rules_scala/blob/2b16342fd8d2dd96b11092caf75d0fd96b8ce253/src/main/scala/higherkindness/rules_scala/workers/zinc/compile/ZincRunner.scala#L292). It most likely originates [here](https://github.com/higherkindness/rules_scala/blob/2b16342fd8d2dd96b11092caf75d0fd96b8ce253/src/main/scala/higherkindness/rules_scala/workers/zinc/compile/ZincPersistence.scala#L45). Immediately before it, we create the `service` directory (or whatever the target's name is). So either the file system is...
:/ Zinc was never made to use ijar, though javac works fine with ijra. And ijar is supposed to basically be a canonicalized form of the interface, but still otherwise...
Do you have multiple instances of this archive_file (like multiple instance of its module)? If so, I suspect Terraform is recreating and hashing the file in parallel, leading to inconsistent...
Though archive_file is problematic for other reasons as well, like being platform specific. https://github.com/hashicorp/terraform-provider-archive/issues/34
> Perhaps because each module instance is recreating the zip and a race condition is causing the hash to be generated when the zip hasn't finished being filled? Correct.
Xtract uses scala-xml, and scala-xml isn't curently compatible with Scala.js.