Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Bazel downstream projects are broken due to out-dated rules_java version with Bazel@HEAD #18551

Closed
meteorcloudy opened this issue Jun 1, 2023 · 2 comments
Closed

Bazel downstream projects are broken due to out-dated rules_java version with Bazel@HEAD #18551

meteorcloudy opened this issue Jun 1, 2023 · 2 comments
Assignees
@meteorcloudy
Labels
breakage P1 I'll work on this now. (Assignee required) team-ExternalDeps External dependency handling, remote repositiories, WORKSPACE file.

Comments

@meteorcloudy
Copy link
Member

meteorcloudy commented Jun 1, 2023 •
edited
Loading

Context

In #18373, we agreed on using rule sets as the source of truth to load toolchains and required dependencies for specific languages (e.g. rules_java, rules_cc). This reduces the duplicated information in Bazel's default @bazel_tools repo and fits our long term goal to make Bazel language-agnostic.

975866a implemented that for rules_java. Unfortunately, this is a breaking change because Bazel now relies on a compatible rules_java version to be defined.

  • When using Bzlmod, this is no problem, because the default bazel_tools module specify a new rules_java version, and thanks to minimal version resolution, we'll always get a compatible rules_java version.
  • When using WORKSPACE, Bazel append a WORKSPACE suffix which defines the compatible rules_java version, however, it could be overridden by user's WORKSPACE content.

Related:

Broken projects

https://buildkite.com/bazel/bazel-at-head-plus-downstream/builds/3066

Potential Solutions

  • Upgrade projects to use newer rules_java. There are too many projects to fix and this is probably not a one-time effort since rules_java is coupled with Bazel's builtin starlarkified java rules.
  • Rename the embedded rules_java in WORKSPACE suffix to rules_java_builtin.
@meteorcloudy meteorcloudy added P1 I'll work on this now. (Assignee required) breakage team-ExternalDeps External dependency handling, remote repositiories, WORKSPACE file. labels Jun 1, 2023
@meteorcloudy meteorcloudy self-assigned this Jun 1, 2023
@meteorcloudy
Copy link
Member Author

I couldn't find any easy fix for this issue, so rolling back the breaking change for now.

copybara-service bot pushed a commit that referenced this issue Jun 1, 2023
@meteorcloudy @copybara-github
Automated rollback of commit 975866a.
d51c75f 
*** Reason for rollback ***

Broke too many downstream projects
#18551

*** Original change description ***

Respect rules_java as the source of truth for java toolchains

Context: #18373

Currently the definitions of java tools, remote JDKs, and Java toolchains are duplicated in both Bazel sources and rules_java, and they go out of sync quite often. By default, the default toolchains shipped with the Bazel binary uses the one in Bazel sources except when Bzlmod is enabled.

https://github.com/bazelb...

***

PiperOrigin-RevId: 537001124
Change-Id: I46cb502328d5c56776b469601cdff0c364164a3a
@meteorcloudy meteorcloudy mentioned this issue Jun 1, 2023
Closed
@meteorcloudy
Copy link
Member Author

Introducing rules_java_builtin seems to work, working on a fix now.

amishra-u pushed a commit to amishra-u/bazel that referenced this issue Jun 7, 2023
@meteorcloudy @amishra-u
Respect rules_java as the source of truth for java toolchains (second…
4e626e2 
… try)

Rolling forward bazelbuild@975866a (which was rollbacked at bazelbuild@d51c75f) with fixes.

- Introduce a `rules_java_builtin` repo in WORKSPACE prefix to avoid conflict with user defined rules_java.
    - `@bazel_tools//tools/jdk/*.bzl` loads from `rules_java_builtin` through repo-mappings.
    - `@local_jdk` was overridden in `jdk.WORKSPACE` to add repo_mapping for `rules_java`.
    - `jdk.WORKSPACE` explicitly loads from `rules_java_builtin` for JDK definitions and java toolchain definitions.
- Allow using `__SKIP_WORKSPACE_PREFIX__` and `__SKIP_WORKSPACE_SUFFIX__` in WORKSPACE comment.
- Fixed many tests by adjusting the WORKSPACE file content.
- Re-export more symbols from `@bazel_tools` to be backward-compatible.

Fixes bazelbuild#18551

Related:
- bazelbuild#18373
- bazelbuild/rules_java#110
- bazelbuild#18423

Closes bazelbuild#18558.

PiperOrigin-RevId: 538483417
Change-Id: I5223eec2c4b10131fc8c5b342237385ff2f56413
copybara-service bot pushed a commit that referenced this issue Jun 14, 2023
@meteorcloudy @copybara-github
Generate repo mapping manifest when it's possible (not only when Bzlm…
cb55897 
…od is enabled).

Related #18551

PiperOrigin-RevId: 540213563
Change-Id: I37051f3ded24e3b7073401b8549a959e392e0dca
traversaro pushed a commit to traversaro/bazel that referenced this issue Jun 24, 2023
@meteorcloudy @traversaro
Generate repo mapping manifest when it's possible (not only when Bzlm…
4410b48 
…od is enabled).

Related bazelbuild#18551

PiperOrigin-RevId: 540213563
Change-Id: I37051f3ded24e3b7073401b8549a959e392e0dca
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@meteorcloudy meteorcloudy

Labels
breakage P1 I'll work on this now. (Assignee required) team-ExternalDeps External dependency handling, remote repositiories, WORKSPACE file.
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Respect rules_java as the source of truth for java toolchains (second try) meteorcloudy/bazel
1 participant
@meteorcloudy