Fresh cherry-pick of the Scala 2.12 support (#304)

[gkk-stripe]

This targets master to show it's one simple commit on top of master. It should be merged to scala_2.12

I had a spare minute and saw comments asking for 2.12 branch. I cherry-picked the original commit for 2.12 branch to start with a clean slate.

Below are original comments from the commit

• 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 #251 (comment)
for the details of the bug.

• Disable jmh test

See #295 for why it's
failing.

• Append YdisableFlatCpCaching to scalacopts by default

Append the YdisableFlatCpCaching compiler option by default as a
workaround to #305

cc @ittaiz @johnynek @andyscott

[johnynek]

we have the wrong base branch here. we don't want to merge into master. Can you change the PR into scala 2.12 branch?

[gkk-stripe]

this targets the right branch: i wanted to show the diff is small, to target 2_2.12, we would need to reset it first to master

[johnynek]

@gkk-stripe but we shouldn't merge this, right?

[gkk-stripe]

no, we shouldn't, to make the story straight: I think we should start 2_12 branch from scratch; the diff between master and 2_12 will be small as this pr demonstrates

[gkk-stripe]

if we get agreement on starting from scratch, I can open a pr against the reset 2_12 branch

[ittaiz]

I think we should start from Scratch but Oscar was hesitant in case people were relying on the commits. I’m actually fairly certain that even if we force push the commits aren’t “lost” so people should be ok. Another option is to push to a new branch 2_12_$date and do that once every few days with cherry picking this commit

…

On Thu, 5 Apr 2018 at 1:42 gkk-stripe ***@***.***> wrote: if we get agreement on starting from scratch, I can open a pr against the reset 2_12 branch — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#472 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABUIF_U-j-MefLwuSsPoL9UL7xNfnUwRks5tlUxKgaJpZM4TFys4> .

[gkossakowski]

we could archive the current head of the branch as a separate branch and reset this one; this way commits won't be GCed

[johnynek]

let's make a new branch but put the old commits in that branch, then reuse the current branch name, which is a better name, for the latest and greatest.

[gkk-stripe]

shall we proceed with the branch for the old commits and push this over?

[johnynek]

I created: https://github.com/bazelbuild/rules_scala/tree/scala2_12_ver0

which is the current scala2_12

now, can we change this commit to go into scala2_12?

[ittaiz]

SGTM

…

On Wed, 18 Apr 2018 at 22:12 P. Oscar Boykin ***@***.***> wrote: I created: https://github.com/bazelbuild/rules_scala/tree/scala2_12_ver0 which is the current scala2_12 now, can we change this commit to go into scala2_12? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#472 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABUIF1RcVCHUif3xNmdJUzOjDsuNZnFZks5tp5AIgaJpZM4TFys4> .

[gkk-stripe]

@johnynek i changed the base to scala_2.12 but it's behind master so the PR appears to be large; can you force push master to scala_2.12 and we'll merge the one cherry-picked commit?

[googlebot]

So there's good news and bad news.

👍 The good news is that everyone that needs to sign a CLA (the pull request submitter and all commit authors) have done so. Everything is all good there.

😕 The bad news is that it appears that one or more commits were authored or co-authored by someone other than the pull request submitter. We need to confirm that all authors are ok with their commits being contributed to this project. Please have them confirm that here in the pull request.

Note to project maintainer: This is a terminal state, meaning the cla/google commit status will not change from this state. It's up to you to confirm consent of the commit author(s) and merge this pull request when appropriate.

[johnynek]

Yeah, I’ll do thit force push tomorrow.

On Wed, Apr 18, 2018 at 10:11 googlebot ***@***.***> wrote: So there's good news and bad news. 👍 The good news is that everyone that needs to sign a CLA (the pull request submitter and all commit authors) have done so. Everything is all good there. 😕 The bad news is that it appears that one or more commits were authored or co-authored by someone other than the pull request submitter. We need to confirm that all authors are ok with their commits being contributed to this project. Please have them confirm that here in the pull request. *Note to project maintainer: This is a terminal state, meaning the cla/google commit status will not change from this state. It's up to you to confirm consent of the commit author(s) and merge this pull request when appropriate.* — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#472 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAEJdvArcZfcTuA5c-sjfM4uC_1qIQM7ks5tp54BgaJpZM4TFys4> .

-- P. Oscar Boykin, Ph.D. | http://twitter.com/posco | http://pobox.com/~boykin

[gkk-stripe]

this is ready for merge

[johnynek]

thanks @gkk-stripe !