-
-
Notifications
You must be signed in to change notification settings - Fork 286
[discussion] Scala 2.12 support #251
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Can one of the admins verify this patch? |
Thanks for your pull request. It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA). 📝 Please visit https://cla.developers.google.com/ to sign. Once you've signed, please reply here (e.g.
|
@@ -0,0 +1 @@ | |||
java_library(name = "transitive_scalatest", exports = ["@scalatest//jar", "@scalactic//jar"]) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
is this still needed?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think so. That's what actually creates a target that depends on scalatest and scalactic.
@ittaiz you might want to take a look. |
@jeremydhoon any ideas about the jmh failure when we bump to 2.12? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @gkossakowski!
2.12 support is definitely something we want to get to.
I think the biggest obstacle before this PR is the need to support cross building #80 which is also something we really want (I guess Wix will need it in a few months as well).
WDYT?
@@ -732,7 +732,7 @@ scala_repl = rule( | |||
|
|||
def scala_version(): | |||
"""return the scala version for use in maven coordinates""" | |||
return "2.11" | |||
return "2.12" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
wouldn't this be a problem? Don't we need to solve #80 (cross building) before merging this PR?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd probably go with the 2.12-specific branch for now and consolidate both when #80 is solved.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see. Main issue to consider is that we're in a few months of adding a host of new features to master so you'll need to catch up if we ever want to merge it in.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A branch is okay, but I share ittaiz anxiety about a long lived branch. I hope we can very quickly get the version configurable.
sha256 = "353f7c2bdde22c4286ee6a3ae0e425a9463b102f4c4cf76055a24f4666996762", | ||
) | ||
|
||
# scalatest has macros, note http_jar is invoking ijar |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't understand how the comment and the code fit together. Doesn't the ijar mess things up? I hope to send late next week a PR to add scala_import
which will disable ijar (maybe with an option to turn it on)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This code predates me and I don't understand how all pieces fit together, either.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ijar destroys macros because it removes all code attributes from the jars. So if a dependency has macros it cannot filter through ijar.
One approach to solve this, is as ittaiz said, just build a scala_import
that always (or by default) doesn't use ijar.
I don't know how what you have here can actually be working since it seems like you are stripping the macros, but maybe it isn't working yet.
@@ -9,7 +9,7 @@ load("//scala:scala.bzl", | |||
def twitter_scrooge(): | |||
native.maven_server( | |||
name = "twitter_scrooge_maven_server", | |||
url = "http://mirror.bazel.build/repo1.maven.org/maven2/", | |||
url = "http://repo1.maven.org/maven2/", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
why remove the mirror?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It wasn't intentional, I think. Probably a hasty copy&paste.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wonder if you could factor this currently into a second function: def twitter_scrooge_2_12()
or something. Then we could actually merge changes like this into the mainline and just switch which repositories we set up.
Using this branch combined with |
Would it be possible to make 2.12 a configurable option or kept on a separate branch/tag until that's possible? I ask because the upgrade path for scala is kind of painful when it comes to 3rd party scala library dependecies for even minor version bumps in the language. I indend to pull in these bazel rules in more often that I upgrade scala versions and i dont have plans to upgrade to 2.12 soon. That may be just me though. I can see the inverse side of this with these rules locked into 2.11 being a blocker for those looking forward to to 2.12 upgrade ( and all of the fun 3rd party lib upgrades that come along with that :) ) |
Two things:
1) the bazel-deps tool I wrote made it pretty easy for us to try this
internally.
2) I don't think we should merge this until we can make scala version
selectable. Definitely not force everyone into scala 2.12, and I'd rather
not have two branches, although that may be the only tractable thing if
ijar is really broken on 2.12.
On Thu, Sep 7, 2017 at 19:54 doug tangren ***@***.***> wrote:
Would it be possible to make 2.12 a configurable option or kept on a
separate branch/tag until that's possible? I ask because the upgrade path
for scala is kind of painful when it comes to 3rd party scala library
dependecies for even minor version bumps in the language. I indend to pull
in these bazel rules in more often that I upgrade scala versions and i dont
have plans to upgrade to 2.12 soon. That may be just me though. I can see
the inverse side of this with these rules locked into 2.11 being a blocker
for those looking forward to to 2.12 upgrade ( and all of the fun 3rd party
lib upgrades that come along with that :) )
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#251 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAEJdtGjI9YfnlsJpkUERZt5qhikemwEks5sgNaAgaJpZM4OWWZP>
.
--
P. Oscar Boykin, Ph.D. | http://twitter.com/posco | http://pobox.com/~boykin
|
+1 to what @johnynek said |
The problem isn't necessarily bumping artifact identifiers, it's doing the work to find out if library authors have actually republished the same version for the newer scala version, and if they did making sure than that didn't accidentally come along with a new library version changes :). And if library authors haven't republished a library version for a newer version of scala, it's a problem being blocked until they do. |
@jbalogh-stripe to be clear: is this only with workers enabled? |
Right. Without |
Hi, sorry for dropping the ball on this. I was busy with other plots at Stripe. The 2.12 migration is back on my list of active threads now. I think we should have a 2.12-specific branch where people interested in finding and fixing 2.12 upgrade issues can work together. |
Regarding interface changes, is |
Bump dependencies to versions that support Scala 2.12.
They swapped the logger interface and now there's a different went to silence the logging.
Newer versions of scalatest have scalactic as a dependency. Let bazel know about it and add its a transitive dep.
If I'm not mistaken the major difference between worker and not is how we pass it the arguments and possibly if we're somehow leaking state in the worker. The logical code, amongst it the calling for Re |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it seems like most, or all of these changes could be made to mainline by making separate repository loading functions suffixed by 2_12, which would make it possible to set a version by the user, but maybe not the standard bazel toolchain way.
sha256 = "353f7c2bdde22c4286ee6a3ae0e425a9463b102f4c4cf76055a24f4666996762", | ||
) | ||
|
||
# scalatest has macros, note http_jar is invoking ijar |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ijar destroys macros because it removes all code attributes from the jars. So if a dependency has macros it cannot filter through ijar.
One approach to solve this, is as ittaiz said, just build a scala_import
that always (or by default) doesn't use ijar.
I don't know how what you have here can actually be working since it seems like you are stripping the macros, but maybe it isn't working yet.
@@ -732,7 +732,7 @@ scala_repl = rule( | |||
|
|||
def scala_version(): | |||
"""return the scala version for use in maven coordinates""" | |||
return "2.11" | |||
return "2.12" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A branch is okay, but I share ittaiz anxiety about a long lived branch. I hope we can very quickly get the version configurable.
@@ -9,7 +9,7 @@ load("//scala:scala.bzl", | |||
def twitter_scrooge(): | |||
native.maven_server( | |||
name = "twitter_scrooge_maven_server", | |||
url = "http://mirror.bazel.build/repo1.maven.org/maven2/", | |||
url = "http://repo1.maven.org/maven2/", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wonder if you could factor this currently into a second function: def twitter_scrooge_2_12()
or something. Then we could actually merge changes like this into the mainline and just switch which repositories we set up.
artifact = "org.tpolecat:tut-core_2.11:0.4.8", | ||
sha1 = "fc723eb822494580cc05d6b3b3a6039d2280a5a0", | ||
artifact = "org.tpolecat:tut-core_2.12:0.4.8", | ||
sha1 = "b68b5a52474bf249d1156f5002033498054b813c", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
similar comment about a def tut_repositories_2_12()
as below.
Add a missing dependency on Twitter's util_core from scrooge rule
This makes the code to compile again on my laptop.
baf3bb2
to
18c54ee
Compare
I pushed a branch rebased on latest master. Still all tests except jmh one pass:
|
on the surface, I agree. Would making [0] https://github.com/bazelbuild/rules_scala/blob/master/scala/scala.bzl#L1001 |
nice that you are getting closer. I think you have an asm mismatch. I wonder if scalac embeds a version of asm or if a transitive dependency does. As far as making the functions take parameters, that could work too, but it is just going to be a giant but either way if you like (not like we have compile safety in the rules). |
@@ -20,15 +20,15 @@ specs2_junit_repositories() | |||
# test adding a scala jar: | |||
maven_jar( | |||
name = "com_twitter__scalding_date", | |||
artifact = scala_mvn_artifact("com.twitter:scalding-date:0.16.0-RC4"), | |||
sha1 = "659eb2d42945dea37b310d96af4e12bf83f54d14" | |||
artifact = scala_mvn_artifact("com.twitter:scalding-date:0.17.0"), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we can upgrade this one and the one below in mainline as well right? guessing they have a 2.11 version
I just verified that latest Scala 2.12 nightly build has classpath caching that works in bazel. |
If you turn on bazel workers in your bazel rc it would have also caught it.
On Fri, Sep 29, 2017 at 12:37 Grzegorz Kossakowski ***@***.***> wrote:
so this would catch the problem just in ci? what's being tested when I run bazel
test //test/... locally?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#251 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAEJdsSJfP0R2bQWx8ytPdPk_SrJDMHuks5snXFFgaJpZM4OWWZP>
.
--
P. Oscar Boykin, Ph.D. | http://twitter.com/posco | http://pobox.com/~boykin
|
exciting!
So we don't have to give up all the performance I guess.
…On Fri, Sep 29, 2017 at 12:39 PM, Grzegorz Kossakowski < ***@***.***> wrote:
I just verified that latest Scala 2.12 nightly build has classpath caching
that works in bazel too.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#251 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAEJds-xQD5ipSnTpIr5zZkNV25ySrzNks5snXGSgaJpZM4OWWZP>
.
--
P. Oscar Boykin, Ph.D. | http://twitter.com/posco | http://pobox.com/~boykin
|
Sounds good. I estimate this will be a high priority for us in a month or two. |
Excellent!
Ittai or Oscar, could you create a 2.12 branch off master? I’ll send a PR
with the latest iteration of bazel rules.
…On 30 September 2017 at 11:16, Ittai Zeidman ***@***.***> wrote:
My proposal is to create a 2.12-specific branch where people who care
about 2.12 migration can work together and shake out the bugs like the one
with incremental compilation.
Sounds good. I estimate this will be a high priority for us in a month or
two.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#251 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAAQeftMA2vUjXNE1rttLVbI1hqQxnfLks5snoVugaJpZM4OWWZP>
.
--
gkk
--
gkk
|
Switch to a recent nightly build that has a fix for the flat classpath caching bug that is breaking bazel's incremental compilation when worker is enabled. See bazel-contrib#251 (comment) for the details of the bug.
Fix version numbers of ScalaPB dependencies to be Scala 2.12-specific. # Conflicts: # scala/scala.bzl
Link to an issue explaining the jmh failure is related to Java 8 and not directly caused by the Scala 2.12.
For mysterious reasons, the hash has changed for a build that should be unique. A sign that relying on nightly builds is risky. Yolo for now, though.
This reverts commit 55fd807. Switch back to 2.12.3 until 2.12.4 is released. This will make the testing easier for projects that rely on compiler plugins.
See bazel-contrib#295 for why it's failing.
* Scala 2.12 updates Bump dependencies to versions that support Scala 2.12. * Fix incompatible scrooge api change. They swapped the logger interface and now there's a different went to silence the logging. * Add scalactic as a transitive dep of scalatest Newer versions of scalatest have scalactic as a dependency. Let bazel know about it and add its a transitive dep. * Add a missing dependency on util_core from scrooge rule Add a missing dependency on Twitter's util_core from scrooge rule * Set -source 1.8 and -target 1.8 javac options This makes the code to compile again on my laptop. * Remove dropped args when calling java_common.create_provider The 031e73c restructured java_commmon rule and dropped both `transitive_compile_time_jars` and `transitive_runtime_jars` from that rule. Let's sync scala.bzl with that change. * Upgrade to Scala 2.12.3 * Switch to Scala nightly build with classpath caching fix Switch to a recent nightly build that has a fix for the flat classpath caching bug that is breaking bazel's incremental compilation when worker is enabled. See #251 (comment) for the details of the bug. * Crash jmh with an explanation why it doesn't work Link to an issue explaining the jmh failure is related to Java 8 and not directly caused by the Scala 2.12. * Upgrade the hash of the nightly build For mysterious reasons, the hash has changed for a build that should be unique. A sign that relying on nightly builds is risky. Yolo for now, though. * Revert "Switch to Scala nightly build with classpath caching fix" This reverts commit 55fd807. Switch back to 2.12.3 until 2.12.4 is released. This will make the testing easier for projects that rely on compiler plugins. * Disable jmh test See #295 for why it's failing. * Switch back to bazel maven mirror Not sure why I switched to the main one in the first place. * Revert "Switch back to bazel maven mirror" This reverts commit 4e266fc. It turns out, the bazel mirror is not great for us because it misses some artifacts: ERROR: /Users/gkk/stripe/rules_scala/twitter_scrooge/twitter_scrooge.bzl:46:3: no such package '@util_core//jar': Failed to fetch Maven dependency: Could not transfer artifact com.twitter:util-core_2.12:jar:6.45.0 from/to util_core (http://mirror.bazel.build/repo1.maven.org/maven2/): Forbidden (403) and referenced by '//external:io_bazel_rules_scala/dependency/thrift/util_core'. * Append YdisableFlatCpCaching to scalacopts by default Append the `YdisableFlatCpCaching` compiler option by default as a workaround to #305 * Disable the jmh test in test_run.sh The target is already commented out in BUILD file, but test_run.sh still tries to run it.
Switch to a recent nightly build that has a fix for the flat classpath caching bug that is breaking bazel's incremental compilation when worker is enabled. See bazel-contrib#251 (comment) for the details of the bug.
Switch to a recent nightly build that has a fix for the flat classpath caching bug that is breaking bazel's incremental compilation when worker is enabled. See bazel-contrib#251 (comment) for the details of the bug.
Switch to a recent nightly build that has a fix for the flat classpath caching bug that is breaking bazel's incremental compilation when worker is enabled. See bazel-contrib#251 (comment) for the details of the bug.
* Scala 2.12 updates Bump dependencies to versions that support Scala 2.12. * Fix incompatible scrooge api change. They swapped the logger interface and now there's a different went to silence the logging. * Add scalactic as a transitive dep of scalatest Newer versions of scalatest have scalactic as a dependency. Let bazel know about it and add its a transitive dep. * Add a missing dependency on util_core from scrooge rule Add a missing dependency on Twitter's util_core from scrooge rule * Set -source 1.8 and -target 1.8 javac options This makes the code to compile again on my laptop. * Remove dropped args when calling java_common.create_provider The 031e73c restructured java_commmon rule and dropped both `transitive_compile_time_jars` and `transitive_runtime_jars` from that rule. Let's sync scala.bzl with that change. * Upgrade to Scala 2.12.3 * Switch to Scala nightly build with classpath caching fix Switch to a recent nightly build that has a fix for the flat classpath caching bug that is breaking bazel's incremental compilation when worker is enabled. See bazel-contrib#251 (comment) for the details of the bug. * Crash jmh with an explanation why it doesn't work Link to an issue explaining the jmh failure is related to Java 8 and not directly caused by the Scala 2.12. * Upgrade the hash of the nightly build For mysterious reasons, the hash has changed for a build that should be unique. A sign that relying on nightly builds is risky. Yolo for now, though. * Revert "Switch to Scala nightly build with classpath caching fix" This reverts commit 55fd807. Switch back to 2.12.3 until 2.12.4 is released. This will make the testing easier for projects that rely on compiler plugins. * Disable jmh test See bazel-contrib#295 for why it's failing. * Switch back to bazel maven mirror Not sure why I switched to the main one in the first place. * Revert "Switch back to bazel maven mirror" This reverts commit 4e266fc. It turns out, the bazel mirror is not great for us because it misses some artifacts: ERROR: /Users/gkk/stripe/rules_scala/twitter_scrooge/twitter_scrooge.bzl:46:3: no such package '@util_core//jar': Failed to fetch Maven dependency: Could not transfer artifact com.twitter:util-core_2.12:jar:6.45.0 from/to util_core (http://mirror.bazel.build/repo1.maven.org/maven2/): Forbidden (403) and referenced by '//external:io_bazel_rules_scala/dependency/thrift/util_core'. * Append YdisableFlatCpCaching to scalacopts by default Append the `YdisableFlatCpCaching` compiler option by default as a workaround to bazel-contrib#305 * Disable the jmh test in test_run.sh The target is already commented out in BUILD file, but test_run.sh still tries to run it.
* Scala 2.12 updates Bump dependencies to versions that support Scala 2.12. * Fix incompatible scrooge api change. They swapped the logger interface and now there's a different went to silence the logging. * Add scalactic as a transitive dep of scalatest Newer versions of scalatest have scalactic as a dependency. Let bazel know about it and add its a transitive dep. * Add a missing dependency on util_core from scrooge rule Add a missing dependency on Twitter's util_core from scrooge rule * Set -source 1.8 and -target 1.8 javac options This makes the code to compile again on my laptop. * Remove dropped args when calling java_common.create_provider The 031e73c restructured java_commmon rule and dropped both `transitive_compile_time_jars` and `transitive_runtime_jars` from that rule. Let's sync scala.bzl with that change. * Upgrade to Scala 2.12.3 * Switch to Scala nightly build with classpath caching fix Switch to a recent nightly build that has a fix for the flat classpath caching bug that is breaking bazel's incremental compilation when worker is enabled. See bazel-contrib#251 (comment) for the details of the bug. * Crash jmh with an explanation why it doesn't work Link to an issue explaining the jmh failure is related to Java 8 and not directly caused by the Scala 2.12. * Upgrade the hash of the nightly build For mysterious reasons, the hash has changed for a build that should be unique. A sign that relying on nightly builds is risky. Yolo for now, though. * Revert "Switch to Scala nightly build with classpath caching fix" This reverts commit 55fd807. Switch back to 2.12.3 until 2.12.4 is released. This will make the testing easier for projects that rely on compiler plugins. * Disable jmh test See bazel-contrib#295 for why it's failing. * Switch back to bazel maven mirror Not sure why I switched to the main one in the first place. * Revert "Switch back to bazel maven mirror" This reverts commit 4e266fc. It turns out, the bazel mirror is not great for us because it misses some artifacts: ERROR: /Users/gkk/stripe/rules_scala/twitter_scrooge/twitter_scrooge.bzl:46:3: no such package '@util_core//jar': Failed to fetch Maven dependency: Could not transfer artifact com.twitter:util-core_2.12:jar:6.45.0 from/to util_core (http://mirror.bazel.build/repo1.maven.org/maven2/): Forbidden (403) and referenced by '//external:io_bazel_rules_scala/dependency/thrift/util_core'. * Append YdisableFlatCpCaching to scalacopts by default Append the `YdisableFlatCpCaching` compiler option by default as a workaround to bazel-contrib#305 * Disable the jmh test in test_run.sh The target is already commented out in BUILD file, but test_run.sh still tries to run it.
* Scala 2.12 updates Bump dependencies to versions that support Scala 2.12. * Fix incompatible scrooge api change. They swapped the logger interface and now there's a different went to silence the logging. * Add scalactic as a transitive dep of scalatest Newer versions of scalatest have scalactic as a dependency. Let bazel know about it and add its a transitive dep. * Add a missing dependency on util_core from scrooge rule Add a missing dependency on Twitter's util_core from scrooge rule * Set -source 1.8 and -target 1.8 javac options This makes the code to compile again on my laptop. * Remove dropped args when calling java_common.create_provider The 031e73c restructured java_commmon rule and dropped both `transitive_compile_time_jars` and `transitive_runtime_jars` from that rule. Let's sync scala.bzl with that change. * Upgrade to Scala 2.12.3 * Switch to Scala nightly build with classpath caching fix Switch to a recent nightly build that has a fix for the flat classpath caching bug that is breaking bazel's incremental compilation when worker is enabled. See bazel-contrib#251 (comment) for the details of the bug. * Crash jmh with an explanation why it doesn't work Link to an issue explaining the jmh failure is related to Java 8 and not directly caused by the Scala 2.12. * Upgrade the hash of the nightly build For mysterious reasons, the hash has changed for a build that should be unique. A sign that relying on nightly builds is risky. Yolo for now, though. * Revert "Switch to Scala nightly build with classpath caching fix" This reverts commit 55fd807. Switch back to 2.12.3 until 2.12.4 is released. This will make the testing easier for projects that rely on compiler plugins. * Disable jmh test See bazel-contrib#295 for why it's failing. * Switch back to bazel maven mirror Not sure why I switched to the main one in the first place. * Revert "Switch back to bazel maven mirror" This reverts commit 4e266fc. It turns out, the bazel mirror is not great for us because it misses some artifacts: ERROR: /Users/gkk/stripe/rules_scala/twitter_scrooge/twitter_scrooge.bzl:46:3: no such package '@util_core//jar': Failed to fetch Maven dependency: Could not transfer artifact com.twitter:util-core_2.12:jar:6.45.0 from/to util_core (http://mirror.bazel.build/repo1.maven.org/maven2/): Forbidden (403) and referenced by '//external:io_bazel_rules_scala/dependency/thrift/util_core'. * Append YdisableFlatCpCaching to scalacopts by default Append the `YdisableFlatCpCaching` compiler option by default as a workaround to bazel-contrib#305 * Disable the jmh test in test_run.sh The target is already commented out in BUILD file, but test_run.sh still tries to run it.
* Scala 2.12 updates Bump dependencies to versions that support Scala 2.12. * Fix incompatible scrooge api change. They swapped the logger interface and now there's a different went to silence the logging. * Add scalactic as a transitive dep of scalatest Newer versions of scalatest have scalactic as a dependency. Let bazel know about it and add its a transitive dep. * Add a missing dependency on util_core from scrooge rule Add a missing dependency on Twitter's util_core from scrooge rule Switch to a recent nightly build that has a fix for the flat classpath caching bug that is breaking bazel's incremental compilation when worker is enabled. See bazel-contrib#251 (comment) for the details of the bug. * Disable jmh test See bazel-contrib#295 for why it's failing. * Append YdisableFlatCpCaching to scalacopts by default Append the `YdisableFlatCpCaching` compiler option by default as a workaround to bazel-contrib#305
* Scala 2.12 updates Bump dependencies to versions that support Scala 2.12. * Fix incompatible scrooge api change. They swapped the logger interface and now there's a different went to silence the logging. * Add scalactic as a transitive dep of scalatest Newer versions of scalatest have scalactic as a dependency. Let bazel know about it and add its a transitive dep. * Add a missing dependency on util_core from scrooge rule Add a missing dependency on Twitter's util_core from scrooge rule Switch to a recent nightly build that has a fix for the flat classpath caching bug that is breaking bazel's incremental compilation when worker is enabled. See bazel-contrib#251 (comment) for the details of the bug. * Disable jmh test See bazel-contrib#295 for why it's failing. * Append YdisableFlatCpCaching to scalacopts by default Append the `YdisableFlatCpCaching` compiler option by default as a workaround to bazel-contrib#305
* Scala 2.12 updates Bump dependencies to versions that support Scala 2.12. * Fix incompatible scrooge api change. They swapped the logger interface and now there's a different went to silence the logging. * Add scalactic as a transitive dep of scalatest Newer versions of scalatest have scalactic as a dependency. Let bazel know about it and add its a transitive dep. * Add a missing dependency on util_core from scrooge rule Add a missing dependency on Twitter's util_core from scrooge rule Switch to a recent nightly build that has a fix for the flat classpath caching bug that is breaking bazel's incremental compilation when worker is enabled. See bazel-contrib#251 (comment) for the details of the bug. * Disable jmh test See bazel-contrib#295 for why it's failing. * Append YdisableFlatCpCaching to scalacopts by default Append the `YdisableFlatCpCaching` compiler option by default as a workaround to bazel-contrib#305
* Scala 2.12 updates Bump dependencies to versions that support Scala 2.12. * Fix incompatible scrooge api change. They swapped the logger interface and now there's a different went to silence the logging. * Add scalactic as a transitive dep of scalatest Newer versions of scalatest have scalactic as a dependency. Let bazel know about it and add its a transitive dep. * Add a missing dependency on util_core from scrooge rule Add a missing dependency on Twitter's util_core from scrooge rule Switch to a recent nightly build that has a fix for the flat classpath caching bug that is breaking bazel's incremental compilation when worker is enabled. See bazel-contrib#251 (comment) for the details of the bug. * Disable jmh test See bazel-contrib#295 for why it's failing. * Append YdisableFlatCpCaching to scalacopts by default Append the `YdisableFlatCpCaching` compiler option by default as a workaround to bazel-contrib#305
* Scala 2.12 updates Bump dependencies to versions that support Scala 2.12. * Fix incompatible scrooge api change. They swapped the logger interface and now there's a different went to silence the logging. * Add scalactic as a transitive dep of scalatest Newer versions of scalatest have scalactic as a dependency. Let bazel know about it and add its a transitive dep. * Add a missing dependency on util_core from scrooge rule Add a missing dependency on Twitter's util_core from scrooge rule Switch to a recent nightly build that has a fix for the flat classpath caching bug that is breaking bazel's incremental compilation when worker is enabled. See bazel-contrib#251 (comment) for the details of the bug. * Disable jmh test See bazel-contrib#295 for why it's failing. * Append YdisableFlatCpCaching to scalacopts by default Append the `YdisableFlatCpCaching` compiler option by default as a workaround to bazel-contrib#305
* Scala 2.12 updates Bump dependencies to versions that support Scala 2.12. * Fix incompatible scrooge api change. They swapped the logger interface and now there's a different went to silence the logging. * Add scalactic as a transitive dep of scalatest Newer versions of scalatest have scalactic as a dependency. Let bazel know about it and add its a transitive dep. * Add a missing dependency on util_core from scrooge rule Add a missing dependency on Twitter's util_core from scrooge rule Switch to a recent nightly build that has a fix for the flat classpath caching bug that is breaking bazel's incremental compilation when worker is enabled. See bazel-contrib#251 (comment) for the details of the bug. * Disable jmh test See bazel-contrib#295 for why it's failing. * Append YdisableFlatCpCaching to scalacopts by default Append the `YdisableFlatCpCaching` compiler option by default as a workaround to bazel-contrib#305
This PR bumps dependencies to Scala 2.12 versions.
The output of running tests is: