-
Notifications
You must be signed in to change notification settings - Fork 4.1k
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
Update error prone version to 2.3.4 #11271
Conversation
We are trying to activate additional error prone checks in Gerrit build: [1]. For this purpose I've conducted a new release for java_tools with new error prone version and published it here: [2]. Finally in this CL: [3] we are trying to switch using custom java_tools with bumped error prone version. While doing this, we are running into multiple issues: [4] and: [5]. [5] is particularly annoying, because I have to specify java_toolchain to switch to custom java_tools release. But given that java_tools distribution contains native code, we cannot just add yet another fancy option to the WORKSPACE/.bazelrc file, and can only document to use different options on different platforms: To build on Linux please do this: $ bazel build \
--java_toolchain=@remote_java_tools_linux//:toolchain \
--host_java_toolchain=@remote_java_tools_linux//:toolchain \
:release To build on Mac Os X please do that: $ bazel build \
--java_toolchain=@remote_java_tools_darwin//:toolchain \
--host_java_toolchain=@remote_java_tools_darwin//:toolchain \
:release [1] https://gerrit-review.googlesource.com/c/gerrit/+/235098 |
…nerated code This is a reproducer to the error reported by new error prone version 2.3.4. Note that due to this breakage the last attempt to upgrade Error Prone in Bazel was reverted: [1], [2]. Test Plan: On Linux run: $ bazel build \ --java_toolchain=@remote_java_tools_linux//:toolchain --host_java_toolchain=@remote_java_tools_linux//:toolchain src/main/kotlin/... Note, that this should be executed on Linux platform, because I have not built custom java_tool with this CL included: [3] on Mac Os X yet. [1] bazelbuild/bazel#10023 [2] bazelbuild/bazel@d990746 [3] bazelbuild/bazel#11271
Yun, can you please have a look how this ties into your Debian efforts? |
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.
LGTM
This library is not in Debian anyway. And it's better to depend on a formal version instead of a snapshot.
@meteorcloudy @meisterT Thanks for the feedback. Note, though, that this PR also adds new dependency to Bazel: Ben-Manes caffeine library: [1]. By chance I know, that Gerrit is also relying on the same version: 2.7.0, so that it should be already imported in Google's Monorepo. But is there any special procedure/process to include new third party dependency in Bazel? |
Oh.. I see. Thanks for the notice. I checked the caffeine library is not in Debian. So this will add more difficulties for the effort of getting Bazel into Debian. Check #9408 Is it because the new error prone version requires this library? Besides, the checked in version is 2.8.0 in Google. |
David, how large is the new dependency? |
Sure. The dependency was added in EP tree in this CL: [1] and was updated to 2.7.0 in this CL: [2].
It's 846706 bytes:
[1] google/error-prone@bfb1789 |
@meteorcloudy Thanks for checking! I have sent this PR: [1] to sync Caffeine version in EP tree to 2.8.0. UPDATE Let's wait, if my PR: [1] is approved in EP, I will update this PR and bump Caffeine library to 2.8.0. |
My PR: [1] was merged in EP, so that I will adapt this PR correspondingly. |
af99d21
to
9734be0
Compare
Done. |
Fixes bazelbuild#11272 (first attempt that was reverted: bazelbuild#9286).
9734be0
to
cbfdeed
Compare
Superseded by #11426. |
Fixes #11272 (first attempt that was reverted: #9286).