Update rules_jvm_external 6.3 -> 6.5 #19129

jin · 2024-11-05T04:52:06Z

Fixes java_export loading with RJE and Bazel 8.

with 6.3:

$ USE_BAZEL_VERSION=8.0.0rc2 bazelisk query //java/core:core_mvn-lib --enable_bzlmod
ERROR: /usr/local/google/home/jingwen/code/protobuf/java/core/BUILD.bazel:169:21: //java/core:lite_mvn-lib: no such attribute 'javacopts' in 'java_library' rule
ERROR: /usr/local/google/home/jingwen/code/protobuf/java/core/BUILD.bazel:169:21: //java/core:lite_mvn-lib: no such attribute 'resources' in 'java_library' rule (did you mean 'features'?)
ERROR: /usr/local/google/home/jingwen/code/protobuf/java/core/BUILD.bazel:169:21: //java/core:lite_mvn-lib: no such attribute 'runtime_deps' in 'java_library' rule
ERROR: /usr/local/google/home/jingwen/code/protobuf/java/core/BUILD.bazel:291:21: //java/core:core_mvn-lib: no such attribute 'javacopts' in 'java_library' rule
ERROR: /usr/local/google/home/jingwen/code/protobuf/java/core/BUILD.bazel:291:21: //java/core:core_mvn-lib: no such attribute 'resources' in 'java_library' rule (did you mean 'features'?)
ERROR: /usr/local/google/home/jingwen/code/protobuf/java/core/BUILD.bazel:291:21: //java/core:core_mvn-lib: no such attribute 'runtime_deps' in 'java_library' rule
ERROR: Evaluation of query "//java/core:core_mvn-lib" failed

with 6.5:

$ USE_BAZEL_VERSION=8.0.0rc2 bazelisk query //java/core:core_mvn-lib --enable_bzlmod
WARNING: For repository 'bazel_skylib', the root module requires module version [email protected], but got [email protected] in the resolved dependency graph. Please update the version in your MODULE.bazel or set --check_direct_dependencies=off
WARNING: For repository 'rules_java', the root module requires module version [email protected], but got [email protected] in the resolved dependency graph. Please update the version in your MODULE.bazel or set --check_direct_dependencies=off
WARNING: For repository 'rules_python', the root module requires module version [email protected], but got [email protected] in the resolved dependency graph. Please update the version in your MODULE.bazel or set --check_direct_dependencies=off
WARNING: For repository 'platforms', the root module requires module version [email protected], but got [email protected] in the resolved dependency graph. Please update the version in your MODULE.bazel or set --check_direct_dependencies=off
WARNING: For repository 'zlib', the root module requires module version [email protected], but got [email protected] in the resolved dependency graph. Please update the version in your MODULE.bazel or set --check_direct_dependencies=off
WARNING: For repository 'proto_bazel_features', the root module requires module version [email protected], but got [email protected] in the resolved dependency graph. Please update the version in your MODULE.bazel or set --check_direct_dependencies=off
WARNING: For repository 'com_google_googletest', the root module requires module version [email protected], but got [email protected] in the resolved dependency graph. Please update the version in your MODULE.bazel or set --check_direct_dependencies=off
WARNING: For repository 'rules_proto', the root module requires module version [email protected], but got [email protected] in the resolved dependency graph. Please update the version in your MODULE.bazel or set --check_direct_dependencies=off
//java/core:core_mvn-lib

Note that build still doesn't work with a different failure mode:

$ USE_BAZEL_VERSION=8.0.0rc2 bazelisk build //java/core:core_mvn --enable_bzlmod
ERROR: no such package '@@protobuf+//': The repository '@@protobuf+' could not be resolved: Repository '@@protobuf+' is not defined
ERROR: /usr/local/google/home/jingwen/code/protobuf/java/core/BUILD.bazel:187:14: every rule of type proto_library implicitly depends upon the target '@@protobuf+//:protoc', but this target could not be found because of: no such package '@@protobuf+//': The repository '@@protobuf+' could not be resolved: Repository '@@protobuf+' is not defined
ERROR: Analysis of target '//java/core:core_mvn' failed; build aborted: Analysis failed
INFO: Elapsed time: 12.522s, Critical Path: 0.04s
INFO: 1 process: 1 internal.
ERROR: Build did NOT complete successfully
FAILED:
    Fetching repository @@rules_java++toolchains+remote_java_tools; starting

This should also be cherrypicked into 29.x.

zhangskz · 2024-11-21T22:00:12Z

@jin Thanks Jin! FYI, you can send these to us directly as internal CL's for main instead which should help with running tests and landing these faster. these changes get imported from Github anyways.

zhangskz · 2024-11-21T22:01:25Z

IIRC, we're also waiting on rules_jvm_external 6.6. Is there any value / does this help unblock Bazel 8 to backporting this to 29.x ahead of those addl. fixes?

jin · 2024-11-22T03:41:11Z

Is there any value / does this help unblock Bazel 8 to backporting this to 29.x ahead of those addl. fixes?

Yes, it unblocks Bazel 8, at least it fixes this issue incrementally by picking up bazel-contrib/rules_jvm_external#1273.

rules_jvm_external 6.6

Can you confirm what exactly you're waiting for in 6.6? From our end, we are aware of bazel-contrib/rules_jvm_external@3ed7d65 and our rules_android dependency bump.

acozzette · 2024-11-26T17:51:40Z

The "Java / Linux Bazel 7 with Bzlmod" test run is failing, so I think that is the one blocker to landing this change.

zhangskz · 2024-11-26T22:13:36Z

I don't really understand why bazel-contrib/rules_jvm_external#1273 fixes the above issue, if protobuf already specifies rules_java 7.12.2. Doesn't MVS mean rules_java 7.12.2 gets selected even prior to this change?

And yeah, I think that's the same set of changes I'm aware of for rules_java 6.6.

We'll likely proceed with v29.0 release first, but can include this in a subsequent patch to v29.x for Bazel 8.

github-actions · 2025-03-24T10:02:27Z

We triage inactive PRs and issues in order to make it easier to find active work. If this PR should remain active, please add a comment.

This PR is labeled inactive because the last activity was over 90 days ago. This PR will be closed and archived after 14 additional days without activity.

github-actions · 2025-04-08T10:02:07Z

We triage inactive PRs and issues in order to make it easier to find active work. If this PR should remain active or becomes active again, please reopen it.

This PR was closed and archived because there has been no new activity in the 14 days since the inactive label was added.

mbland · 2025-06-13T03:46:51Z

FYI, I hit this exact error today, while working on bazel-contrib/rules_scala#1747, testing with:

Bazel 8.2.1, protobuf v31.1, rules_java 8.12.0
--noenable_bzlmod --enable_workspace --incompatible_autoload_externally= (set in .bazelrc)

This is because 73401b0 updated rules_jvm_external to 6.5 in MODULE.bazel for v31.0, but missed it in //:protobuf_deps.bzl.

I'm happy to open a PR on this repo to update //:protocol_deps.bzl, if that would help.

(As a workaround, I'm about to file a rules_scala pull request to update //scala:latest_deps.bzl to explicitly include rules_jvm_external 6.7, which we didn't explicitly depend upon before.)

I'm pretty sure bazel-contrib/rules_jvm_external#1273 isn't what necessitated the bump to rules_jvm_external 6.5.

bazel-contrib/rules_jvm_external#1271 updated private/rules/java_export.bzl to replace native.java_library with java_library from @rules_java//java:defs.bzl. The merge commit from that pull request first landed in rules_jvm_external 6.5.

Output from failing //java/core:lite_mvn-lib target in rules_scala build

$ bazel build --test_output=errors src/... test/...

ERROR: .../external/com_google_protobuf/java/core/BUILD.bazel:169:21:
  @@com_google_protobuf//java/core:lite_mvn-lib:
  no such attribute 'javacopts' in 'java_library' rule

ERROR: .../external/com_google_protobuf/java/core/BUILD.bazel:169:21:
  @@com_google_protobuf//java/core:lite_mvn-lib:
  no such attribute 'resources' in 'java_library' rule
  (did you mean 'features'?)

ERROR: .../external/com_google_protobuf/java/core/BUILD.bazel:169:21:
  @@com_google_protobuf//java/core:lite_mvn-lib:
  no such attribute 'runtime_deps' in 'java_library' rule

ERROR: .../external/com_google_protobuf/java/core/BUILD.bazel:287:21:
  @@com_google_protobuf//java/core:core_mvn-lib:
  no such attribute 'javacopts' in 'java_library' rule

ERROR: .../external/com_google_protobuf/java/core/BUILD.bazel:287:21:
  @@com_google_protobuf//java/core:core_mvn-lib:
  no such attribute 'resources' in 'java_library' rule (did you mean 'features'?)

ERROR: .../external/com_google_protobuf/java/core/BUILD.bazel:287:21:
  @@com_google_protobuf//java/core:core_mvn-lib:
  no such attribute 'runtime_deps' in 'java_library' rule

ERROR: .../external/com_google_protobuf/BUILD.bazel:475:6:
  Target '@@com_google_protobuf//java/core:core'
  contains an error and its package is in error
  and referenced by '@@com_google_protobuf//:protobuf_java'

ERROR: Analysis of target
  '//test/proto/custom_generator:failing_scala_proto_deps_toolchain_def'
  failed; build aborted: Analysis failed

I added --incompatible_autoload_externally= to resolve an apparent @@bazel_features_version//:version.bzl cycle, the error message referencing bazelbuild/bazel#23043:

$ bazel run //tools:lint_check

ERROR: Cycle caused by autoloads, failed to load .bzl file
  '@@bazel_features_version//:version.bzl'.
Add 'bazel_features_version' to --repositories_without_autoloads
  or disable autoloads by setting '--incompatible_autoload_externally='
More information on https://github.com/bazelbuild/bazel/issues/23043.

Building with Bazel 7.6.1 under WORKSPACE worked, as --incompatible_autoload_externally= seems to be a no-op in that version (despite bazelbuild/bazel#23906).

Building under Bzlmod with --incompatible_autoload_externally= worked with Bazel 7, 8, rolling and last_green.

Fixes a few problems when building under `WORKSPACE` with Bazel 8.2.1 (7.6.1 doesn't require these changes). Adds to `.bazelrc` the `--incompatible_autoload_externally=` flag as a common option for all builds, and a (disabled) line of options for `WORKSPACE` builds. Bumps these development dependency versions: - `com_google_buildifier_buildtools`: 5.1.0 => 8.2.1 - `rules_shell`: 0.4.1 => 0.5.0 --- Though `WORKSPACE` is on the way out, we should ensure that `rules_scala` remains as compatible as it can be until it's totally gone. All of these errors happened when running `./test_all` with Bazel 8.2.1 and `WORKSPACE` enabled while working on bazel-contrib#1747. The first error was the following "cycle". (I later realized it's somehow due to bazelbuild/rules_java#294 from `rules_java` 8.12.0. See the note at the very end below.) ```sh $ bazel run //tools:lint_check ERROR: Cycle caused by autoloads, failed to load .bzl file '@@bazel_features_version//:version.bzl'. Add 'bazel_features_version' to --repositories_without_autoloads or disable autoloads by setting '--incompatible_autoload_externally=' More information on bazelbuild/bazel#23043. ``` `--incompatible_autoload_externally=` fixed this problem, but also precipitated all the other errors below. - bazelbuild/bazel#23043 - https://bazel.build/reference/command-line-reference#common_options-flag--incompatible_autoload_externally Updating `com_github_bazelbuild_buildtools` to v8.2.1 fixes the next error, whereby Bazel no longer autoloaded `sh_test`. v5.1.0 was missing the required `load("@rules_shell//shell:sh_test.bzl", "sh_test")` statement, added in v8.0.3 by bazelbuild/buildtools#1332: ```sh $ bazel run //tools:lint_check ERROR: .../external/com_github_bazelbuild_buildtools/buildifier/BUILD.bazel:60:1: name 'sh_test' is not defined (did you mean 'cc_test'?) ERROR: .../external/com_github_bazelbuild_buildtools/buildifier/BUILD.bazel: no such target '@@com_github_bazelbuild_buildtools//buildifier:runner.bash.template': target 'runner.bash.template' not declared in package 'buildifier' defined by .../external/com_github_bazelbuild_buildtools/buildifier/BUILD.bazel; however, a source file of this name exists. (Perhaps add 'exports_files(["runner.bash.template"])' to buildifier/BUILD?) ERROR: /Users/mbland/src/bazel-contrib/rules_scala/tools/BUILD:19:11: every rule of type _buildifier implicitly depends upon the target '@@com_github_bazelbuild_buildtools//buildifier:runner.bash.template', but this target could not be found because of: no such target '@@com_github_bazelbuild_buildtools//buildifier:runner.bash.template': target 'runner.bash.template' not declared in package 'buildifier' defined by .../external/com_github_bazelbuild_buildtools/buildifier/BUILD.bazel; however, a source file of this name exists. (Perhaps add 'exports_files(["runner.bash.template"])' to buildifier/BUILD?) ERROR: Analysis of target '//tools:lint_check' failed; build aborted: Analysis failed ``` Upgrading to v8.2.1 and updating `//tools:lint_check` to become a `buildifier_test` also finally got rid of this next warning. This required exporting the `MODULE.bazel` file from the root package, disabling one lint warning, and accepting a couple of new lint fixes: ```txt DEBUG: .../external/+dev_deps+com_github_bazelbuild_buildtools/buildifier/internal/factory.bzl:17:10: DEPRECATION NOTICE: value 'check' for attribute 'mode' will be removed in the future. Migrate '@@//tools:lint_check' to buildifier_test. ``` Adding `rules_jvm_external` 6.7 to `//scala:latest_deps.bzl` fixes this next error, described in detail in: - protocolbuffers/protobuf#19129 (comment) ```sh $ bazel build --test_output=errors src/... test/... ERROR: .../external/com_google_protobuf/java/core/BUILD.bazel:169:21: @@com_google_protobuf//java/core:lite_mvn-lib: no such attribute 'javacopts' in 'java_library' rule ERROR: .../external/com_google_protobuf/java/core/BUILD.bazel:169:21: @@com_google_protobuf//java/core:lite_mvn-lib: no such attribute 'resources' in 'java_library' rule (did you mean 'features'?) ERROR: .../external/com_google_protobuf/java/core/BUILD.bazel:169:21: @@com_google_protobuf//java/core:lite_mvn-lib: no such attribute 'runtime_deps' in 'java_library' rule ERROR: .../external/com_google_protobuf/java/core/BUILD.bazel:287:21: @@com_google_protobuf//java/core:core_mvn-lib: no such attribute 'javacopts' in 'java_library' rule ERROR: .../external/com_google_protobuf/java/core/BUILD.bazel:287:21: @@com_google_protobuf//java/core:core_mvn-lib: no such attribute 'resources' in 'java_library' rule (did you mean 'features'?) ERROR: .../external/com_google_protobuf/java/core/BUILD.bazel:287:21: @@com_google_protobuf//java/core:core_mvn-lib: no such attribute 'runtime_deps' in 'java_library' rule ERROR: .../external/com_google_protobuf/BUILD.bazel:475:6: Target '@@com_google_protobuf//java/core:core' contains an error and its package is in error and referenced by '@@com_google_protobuf//:protobuf_java' ERROR: Analysis of target '//test/proto/custom_generator:failing_scala_proto_deps_toolchain_def' failed; build aborted: Analysis failed ``` All of the previous errors only affected `rules_scala`'s own development builds and test runs, when it is the main repository/root module. This final error is something users could possibly run into when using `--incompatible_autoload_externally=` with `rules_scala`. `jvm_import` statements in Maven dependency repos generated by `jvm_import_external` from `//scala:scala_maven_import_external.bzl` began to fail. Defining `_JAVA_IMPORT_RULE_LOAD` and using it as the default value for the `rule_load` attribute of the `_jvm_import_external` rule fixed this: ```sh $ bazel test --test_output=errors third_party/... ERROR: .../external/org_apache_commons_commons_lang_3_5_without_file/BUILD:7:12: @@org_apache_commons_commons_lang_3_5_without_file//:org_apache_commons_commons_lang_3_5_without_file: no such attribute 'jars' in 'java_import' rule ERROR: .../external/org_apache_commons_commons_lang_3_5_without_file/BUILD:7:12: @@org_apache_commons_commons_lang_3_5_without_file//:org_apache_commons_commons_lang_3_5_without_file: no such attribute 'neverlink' in 'java_import' rule ERROR: .../external/org_apache_commons_commons_lang_3_5_without_file/BUILD:14:12: @@org_apache_commons_commons_lang_3_5_without_file//:linkable_org_apache_commons_commons_lang_3_5_without_file: no such attribute 'jars' in 'java_import' rule ERROR: .../third_party/dependency_analyzer/src/test/BUILD:4:6: Target '@@org_apache_commons_commons_lang_3_5_without_file//:linkable_org_apache_commons_commons_lang_3_5_without_file' contains an error and its package is in error and referenced by '//third_party/dependency_analyzer/src/test:strict_deps_test' ERROR: Analysis of target '//third_party/dependency_analyzer/src/test:strict_deps_test' failed; build aborted: Analysis failed ``` --- And just now, I'm noticing that I'd already added the following to `.bazelrc`, where the `rules_java` release references bazelbuild/bazel#26119: ```sh # Uncomment for WORKSPACE builds for Bazel [8.0.0, 8.3.0) per: # https://github.com/bazelbuild/rules_java/releases/tag/8.12.0 #common --repositories_without_autoloads=bazel_features_version,bazel_features_globals ``` Oh well. But now we're future proof.

zhangskz · 2025-06-13T14:21:52Z

Please feel free to send us a PR updating //:protocol_deps.bzl to match. That indeed seems like an oversight!

Commit 73401b0 updated bazel-contrib/rules_jvm_external to 6.5 in `MODULE.bazel` for v31.0, but missed it in `//:protobuf_deps.bzl`. This caused `WORKSPACE` builds to break under Bazel 8.2.1 with `rules_java` 8.12.0 and `--incompatible_autoload_externally=`: - protocolbuffers#19129 (comment) Confirmed that this change fixes the breakage when building the following target in bazel-contrib/rules_scala: ``` USE_BAZEL_VERSION=8.2.1 bazel build \ --noenable_bzlmod --enable_workspace \ --incompatible_autoload_externally= \ //test/proto/custom_generator:failing_scala_proto_deps_toolchain_def ```

mbland · 2025-06-13T15:04:39Z

Please feel free to send us a PR updating //:protocol_deps.bzl to match. That indeed seems like an oversight!

@zhangskz Just opened #22225. Thanks!

Also, I realized late last night after posting my comment that I'd forgotten that the rules_java 8.12.0 release notes mentioned requiring:

# https://github.com/bazelbuild/bazel/pull/26119
common --repositories_without_autoloads=bazel_features_version,bazel_features_globals

I'd had that commented out in the .bazelrc file from rules_scala and forgotten about in the face of the error message suggesting --incompatible_autoload_externally=. D'oh! But at least it led me to detect a small, yet legitimate issue worth fixing.

Commit 73401b0 updated bazel-contrib/rules_jvm_external to 6.5 in `MODULE.bazel` for v31.0, but missed it in `//:protobuf_deps.bzl`. This caused `WORKSPACE` builds to break under Bazel 8.2.1 with `rules_java` 8.12.0 and `--incompatible_autoload_externally=`: - #19129 (comment) Confirmed that this change fixes the breakage when building the following target in bazel-contrib/rules_scala: ``` USE_BAZEL_VERSION=8.2.1 bazel build \ --noenable_bzlmod --enable_workspace \ --incompatible_autoload_externally= \ //test/proto/custom_generator:failing_scala_proto_deps_toolchain_def ``` Closes #22225 COPYBARA_INTEGRATE_REVIEW=#22225 from mbland:mbland-19129-add-rules-jvm-external-6-7-to-protobuf-deps-bzl fa0a12b PiperOrigin-RevId: 771302937

Fixes a few problems when building under `WORKSPACE` with Bazel 8.2.1 (7.6.1 doesn't require these changes). Adds to `.bazelrc` the `--incompatible_autoload_externally=` flag as a common option for all builds, and a (disabled) line of options for `WORKSPACE` builds. Bumps these development dependency versions: - `com_google_buildifier_buildtools`: 5.1.0 => 8.2.1 - `rules_shell`: 0.4.1 => 0.5.0 --- Though `WORKSPACE` is on the way out, we should ensure that `rules_scala` remains as compatible as it can be until it's totally gone. All of these errors happened when running `./test_all` with Bazel 8.2.1 and `WORKSPACE` enabled while working on #1747. The first error was the following "cycle". (I later realized it's somehow due to bazelbuild/rules_java#294 from `rules_java` 8.12.0. See the note at the very end below.) ```sh $ bazel run //tools:lint_check ERROR: Cycle caused by autoloads, failed to load .bzl file '@@bazel_features_version//:version.bzl'. Add 'bazel_features_version' to --repositories_without_autoloads or disable autoloads by setting '--incompatible_autoload_externally=' More information on bazelbuild/bazel#23043. ``` `--incompatible_autoload_externally=` fixed this problem, but also precipitated all the other errors below. - bazelbuild/bazel#23043 - https://bazel.build/reference/command-line-reference#common_options-flag--incompatible_autoload_externally Updating `com_github_bazelbuild_buildtools` to v8.2.1 fixes the next error, whereby Bazel no longer autoloaded `sh_test`. v5.1.0 was missing the required `load("@rules_shell//shell:sh_test.bzl", "sh_test")` statement, added in v8.0.3 by bazelbuild/buildtools#1332: ```sh $ bazel run //tools:lint_check ERROR: .../external/com_github_bazelbuild_buildtools/buildifier/BUILD.bazel:60:1: name 'sh_test' is not defined (did you mean 'cc_test'?) ERROR: .../external/com_github_bazelbuild_buildtools/buildifier/BUILD.bazel: no such target '@@com_github_bazelbuild_buildtools//buildifier:runner.bash.template': target 'runner.bash.template' not declared in package 'buildifier' defined by .../external/com_github_bazelbuild_buildtools/buildifier/BUILD.bazel; however, a source file of this name exists. (Perhaps add 'exports_files(["runner.bash.template"])' to buildifier/BUILD?) ERROR: /Users/mbland/src/bazel-contrib/rules_scala/tools/BUILD:19:11: every rule of type _buildifier implicitly depends upon the target '@@com_github_bazelbuild_buildtools//buildifier:runner.bash.template', but this target could not be found because of: no such target '@@com_github_bazelbuild_buildtools//buildifier:runner.bash.template': target 'runner.bash.template' not declared in package 'buildifier' defined by .../external/com_github_bazelbuild_buildtools/buildifier/BUILD.bazel; however, a source file of this name exists. (Perhaps add 'exports_files(["runner.bash.template"])' to buildifier/BUILD?) ERROR: Analysis of target '//tools:lint_check' failed; build aborted: Analysis failed ``` Upgrading to v8.2.1 and updating `//tools:lint_check` to become a `buildifier_test` also finally got rid of this next warning. This required exporting the `MODULE.bazel` file from the root package, disabling one lint warning, and accepting a couple of new lint fixes: ```txt DEBUG: .../external/+dev_deps+com_github_bazelbuild_buildtools/buildifier/internal/factory.bzl:17:10: DEPRECATION NOTICE: value 'check' for attribute 'mode' will be removed in the future. Migrate '@@//tools:lint_check' to buildifier_test. ``` Adding `rules_jvm_external` 6.7 to `//scala:latest_deps.bzl` fixes this next error, described in detail in: - protocolbuffers/protobuf#19129 (comment) ```sh $ bazel build --test_output=errors src/... test/... ERROR: .../external/com_google_protobuf/java/core/BUILD.bazel:169:21: @@com_google_protobuf//java/core:lite_mvn-lib: no such attribute 'javacopts' in 'java_library' rule ERROR: .../external/com_google_protobuf/java/core/BUILD.bazel:169:21: @@com_google_protobuf//java/core:lite_mvn-lib: no such attribute 'resources' in 'java_library' rule (did you mean 'features'?) ERROR: .../external/com_google_protobuf/java/core/BUILD.bazel:169:21: @@com_google_protobuf//java/core:lite_mvn-lib: no such attribute 'runtime_deps' in 'java_library' rule ERROR: .../external/com_google_protobuf/java/core/BUILD.bazel:287:21: @@com_google_protobuf//java/core:core_mvn-lib: no such attribute 'javacopts' in 'java_library' rule ERROR: .../external/com_google_protobuf/java/core/BUILD.bazel:287:21: @@com_google_protobuf//java/core:core_mvn-lib: no such attribute 'resources' in 'java_library' rule (did you mean 'features'?) ERROR: .../external/com_google_protobuf/java/core/BUILD.bazel:287:21: @@com_google_protobuf//java/core:core_mvn-lib: no such attribute 'runtime_deps' in 'java_library' rule ERROR: .../external/com_google_protobuf/BUILD.bazel:475:6: Target '@@com_google_protobuf//java/core:core' contains an error and its package is in error and referenced by '@@com_google_protobuf//:protobuf_java' ERROR: Analysis of target '//test/proto/custom_generator:failing_scala_proto_deps_toolchain_def' failed; build aborted: Analysis failed ``` All of the previous errors only affected `rules_scala`'s own development builds and test runs, when it is the main repository/root module. This final error is something users could possibly run into when using `--incompatible_autoload_externally=` with `rules_scala`. `jvm_import` statements in Maven dependency repos generated by `jvm_import_external` from `//scala:scala_maven_import_external.bzl` began to fail. Defining `_JAVA_IMPORT_RULE_LOAD` and using it as the default value for the `rule_load` attribute of the `_jvm_import_external` rule fixed this: ```sh $ bazel test --test_output=errors third_party/... ERROR: .../external/org_apache_commons_commons_lang_3_5_without_file/BUILD:7:12: @@org_apache_commons_commons_lang_3_5_without_file//:org_apache_commons_commons_lang_3_5_without_file: no such attribute 'jars' in 'java_import' rule ERROR: .../external/org_apache_commons_commons_lang_3_5_without_file/BUILD:7:12: @@org_apache_commons_commons_lang_3_5_without_file//:org_apache_commons_commons_lang_3_5_without_file: no such attribute 'neverlink' in 'java_import' rule ERROR: .../external/org_apache_commons_commons_lang_3_5_without_file/BUILD:14:12: @@org_apache_commons_commons_lang_3_5_without_file//:linkable_org_apache_commons_commons_lang_3_5_without_file: no such attribute 'jars' in 'java_import' rule ERROR: .../third_party/dependency_analyzer/src/test/BUILD:4:6: Target '@@org_apache_commons_commons_lang_3_5_without_file//:linkable_org_apache_commons_commons_lang_3_5_without_file' contains an error and its package is in error and referenced by '//third_party/dependency_analyzer/src/test:strict_deps_test' ERROR: Analysis of target '//third_party/dependency_analyzer/src/test:strict_deps_test' failed; build aborted: Analysis failed ``` --- And just now, I'm noticing that I'd already added the following to `.bazelrc`, where the `rules_java` release references bazelbuild/bazel#26119: ```sh # Uncomment for WORKSPACE builds for Bazel [8.0.0, 8.3.0) per: # https://github.com/bazelbuild/rules_java/releases/tag/8.12.0 #common --repositories_without_autoloads=bazel_features_version,bazel_features_globals ``` Oh well. But now we're future proof.

Fixes the runfiles problems with Windows builds for Bazel 8 and later seen in bazelbuild/bazel-central-registry#5490. Bumps a number of dependencies, and bumps the `rules_scala` version in `MODULE.bazel` from `7.1.0` to `7.1.1`. Dependency version bumps include: - Go: 1.24.5 => 1.25.0 - `golang.org/x/tools`: v0.35.0 => v0.36.0 - `jline`: 3.30.4 => 3.30.5 - `protobuf-java`: 4.31.1 => 4.32.0 - `protobuf`: v31.1 => v32.0 - `rules_java`: 8.15.0 => 8.15.1 - `rules_python`: 1.5.2 => 1.5.3 Also: - Restores `examples/crossbuild/protobuf.patch` to a symlink, undoing the change from bazel-contrib#1760. - Fixes precompiled Windows protoc selection on ARM64 in `protoc/private/protoc_toolchains.bzl`. - Removes `RULES_SCALA_MAIN_WS_NAME` from the ScalaTest runner implementation. - Removes `rules_jvm_external` from `scala/latest_deps.bzl`. --- bazelbuild/continuous-integration#2350 resolved the Windows symlink problem, fixing the bazelbuild/bazel-central-registry#5490 Bazel 7 Windows build. This enables the restoration of the original `examples/crossbuild/protobuf.patch` symlink, effectively closing bazelbuild/bazel-central-registry#5506. The `src/java/io/bazel/rulesscala/exe/LauncherFileWriter.java` changes fix the remaining bazelbuild/bazel-central-registry#5490 breakages. Specifically, adding the `.exe` suffix only when necessary under Bazel 7 fixes the Windows builds for Bazel 8 and later. However, we'll have to close that pull request and push the v7.1.1 tag to begin a new release. The updates to use `@AutoBazelRepository` and `Runfiles.preload()`, etc. are from the `com.google.devtools.build.Runfiles` docstring: - https://github.com/bazelbuild/rules_java/blob/8.15.1/java/runfiles/src/main/java/com/google/devtools/build/runfiles/Runfiles.java#L31-L134 `RULES_SCALA_MAIN_WS_NAME` is no longer necessary given proper runfiles library usage, and technically became obsolete in commit f758956. Instantiating `rules_jvm_external` ourselves is no longer necessary because `protobuf` v32.0 contains protocolbuffers/protobuf#22225, which closed protocolbuffers/protobuf#19129. I've tested this change using my personal Windows 11 ARM64 virtual machine, hence the updates to `protoc/private/protoc_toolchains.bzl`. Previously, the `exec_compatible_with` attribute of the toolchain target contained `@platforms//cpu:x86_64` instead of `@platforms//cpu:aarch64`. This caused `@protobuf//bazel/private:proto_toolchain_type` to resolve to `@protobuf//bazel/private/toolchains:protoc_sources`, triggering recompilation. I also had to use `python.single_version_platform_override` and to fix `@bazel_tools//tools/jdk:proguard_whitelister` on Windows ARM64. This is because the latest `rules_python` 1.5.3 doesn't contain any entries for `aarch64-pc-windows-msvc` in `//python:versions.bzl`. However, it appears such entries are coming in the next `rules_python` release, which will eliminate the need for such a workaround. For that reason, I haven't tried to include it in this change. - https://github.com/bazelbuild/bazel/blob/7.6.1/tools/jdk/BUILD.tools#L133-L138 - https://github.com/bazel-contrib/rules_python/blob/1.5.3/python/versions.bzl - https://github.com/astral-sh/python-build-standalone/releases/ - https://rules-python.readthedocs.io/en/latest/api/rules_python/python/extensions/python.html#python.single_version_platform_override - bazel-contrib/rules_python#2276 - bazel-contrib/rules_python#3062 - bazel-contrib/rules_python#3074 - bazel-contrib/rules_python#3116 A couple of interesting new facts I learned about `protobuf` in the process of producing this change: - v32.0 officially drops support for Bazel 6: https://github.com/protocolbuffers/protobuf/releases/tag/v32.0 protocolbuffers/protobuf@da0077e - v34 isn't dropping MSVC support after all: https://protobuf.dev/news/2025-07-16/ protocolbuffers/protobuf#20085 protocolbuffers/protobuf#20085 (comment)

Fixes the runfiles problems with Windows builds for Bazel 8 and later seen in bazelbuild/bazel-central-registry#5490. Bumps a number of dependencies, and bumps the `rules_scala` version in `MODULE.bazel` from `7.1.0` to `7.1.1`. Dependency version bumps include: - Go: 1.24.5 => 1.25.0 - `golang.org/x/tools`: v0.35.0 => v0.36.0 - `jline`: 3.30.4 => 3.30.5 - `protobuf-java`: 4.31.1 => 4.32.0 - `protobuf`: v31.1 => v32.0 - `rules_java`: 8.15.0 => 8.15.1 - `rules_python`: 1.5.2 => 1.5.3 Also: - Restores `examples/crossbuild/protobuf.patch` to a symlink, undoing the change from #1760. - Fixes precompiled Windows protoc selection on ARM64 in `protoc/private/protoc_toolchains.bzl`. - Removes `RULES_SCALA_MAIN_WS_NAME` from the ScalaTest runner implementation. - Removes `rules_jvm_external` from `scala/latest_deps.bzl`. --- bazelbuild/continuous-integration#2350 resolved the Windows symlink problem, fixing the bazelbuild/bazel-central-registry#5490 Bazel 7 Windows build. This enables the restoration of the original `examples/crossbuild/protobuf.patch` symlink, effectively closing bazelbuild/bazel-central-registry#5506. The `src/java/io/bazel/rulesscala/exe/LauncherFileWriter.java` changes fix the remaining bazelbuild/bazel-central-registry#5490 breakages. Specifically, adding the `.exe` suffix only when necessary under Bazel 7 fixes the Windows builds for Bazel 8 and later. However, we'll have to close that pull request and push the v7.1.1 tag to begin a new release. The updates to use `@AutoBazelRepository` and `Runfiles.preload()`, etc. are from the `com.google.devtools.build.Runfiles` docstring: - https://github.com/bazelbuild/rules_java/blob/8.15.1/java/runfiles/src/main/java/com/google/devtools/build/runfiles/Runfiles.java#L31-L134 `RULES_SCALA_MAIN_WS_NAME` is no longer necessary given proper runfiles library usage, and technically became obsolete in commit f758956. Instantiating `rules_jvm_external` ourselves is no longer necessary because `protobuf` v32.0 contains protocolbuffers/protobuf#22225, which closed protocolbuffers/protobuf#19129. I've tested this change using my personal Windows 11 ARM64 virtual machine, hence the updates to `protoc/private/protoc_toolchains.bzl`. Previously, the `exec_compatible_with` attribute of the toolchain target contained `@platforms//cpu:x86_64` instead of `@platforms//cpu:aarch64`. This caused `@protobuf//bazel/private:proto_toolchain_type` to resolve to `@protobuf//bazel/private/toolchains:protoc_sources`, triggering recompilation. I also had to use `python.single_version_platform_override` and to fix `@bazel_tools//tools/jdk:proguard_whitelister` on Windows ARM64. This is because the latest `rules_python` 1.5.3 doesn't contain any entries for `aarch64-pc-windows-msvc` in `//python:versions.bzl`. However, it appears such entries are coming in the next `rules_python` release, which will eliminate the need for such a workaround. For that reason, I haven't tried to include it in this change. - https://github.com/bazelbuild/bazel/blob/7.6.1/tools/jdk/BUILD.tools#L133-L138 - https://github.com/bazel-contrib/rules_python/blob/1.5.3/python/versions.bzl - https://github.com/astral-sh/python-build-standalone/releases/ - https://rules-python.readthedocs.io/en/latest/api/rules_python/python/extensions/python.html#python.single_version_platform_override - bazel-contrib/rules_python#2276 - bazel-contrib/rules_python#3062 - bazel-contrib/rules_python#3074 - bazel-contrib/rules_python#3116 A couple of interesting new facts I learned about `protobuf` in the process of producing this change: - v32.0 officially drops support for Bazel 6: https://github.com/protocolbuffers/protobuf/releases/tag/v32.0 protocolbuffers/protobuf@da0077e - v34 isn't dropping MSVC support after all: https://protobuf.dev/news/2025-07-16/ protocolbuffers/protobuf#20085 protocolbuffers/protobuf#20085 (comment)

jin requested a review from a team as a code owner November 5, 2024 04:52

jin requested review from haberman and removed request for a team November 5, 2024 04:52

zhangskz added the 🅰️ safe for tests Mark a commit as safe to run presubmits over label Nov 21, 2024

github-actions bot removed the 🅰️ safe for tests Mark a commit as safe to run presubmits over label Nov 21, 2024

tonyliaoss assigned tonyliaoss and zhangskz and unassigned tonyliaoss Nov 21, 2024

tonyliaoss requested a review from zhangskz November 21, 2024 21:59

zhangskz approved these changes Nov 21, 2024

View reviewed changes

Update rules_jvm_external 6.3 -> 6.5

5fe49d6

jin force-pushed the RJE_6.5 branch from d8cdcf4 to 5fe49d6 Compare November 22, 2024 03:56

tonyliaoss added the 🅰️ safe for tests Mark a commit as safe to run presubmits over label Nov 22, 2024

github-actions bot removed the 🅰️ safe for tests Mark a commit as safe to run presubmits over label Nov 22, 2024

JasonLunn added bazel wait for user action labels Dec 23, 2024

JasonLunn removed the request for review from haberman December 23, 2024 22:29

github-actions bot added the inactive Denotes the issue/PR has not seen activity in the last 90 days. label Mar 24, 2025

github-actions bot closed this Apr 8, 2025

mbland mentioned this pull request Jun 13, 2025

Fix Bazel 8.2.1 WORKSPACE builds, bump dev deps bazel-contrib/rules_scala#1748

Merged

mbland mentioned this pull request Jun 13, 2025

Add rules_jvm_external 6.7 to protobuf_deps.bzl #22225

Closed

mbland mentioned this pull request Aug 15, 2025

Update Runfiles usage to fix BCR, bump versions bazel-contrib/rules_scala#1761

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Update rules_jvm_external 6.3 -> 6.5 #19129

Update rules_jvm_external 6.3 -> 6.5 #19129

Uh oh!

jin commented Nov 5, 2024 •

edited

Loading

Uh oh!

zhangskz commented Nov 21, 2024

Uh oh!

zhangskz commented Nov 21, 2024

Uh oh!

jin commented Nov 22, 2024 •

edited

Loading

Uh oh!

acozzette commented Nov 26, 2024

Uh oh!

zhangskz commented Nov 26, 2024

Uh oh!

github-actions bot commented Mar 24, 2025

Uh oh!

github-actions bot commented Apr 8, 2025

Uh oh!

mbland commented Jun 13, 2025

Uh oh!

zhangskz commented Jun 13, 2025

Uh oh!

mbland commented Jun 13, 2025

Uh oh!

Uh oh!

Update rules_jvm_external 6.3 -> 6.5 #19129

Update rules_jvm_external 6.3 -> 6.5 #19129

Uh oh!

Conversation

jin commented Nov 5, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

zhangskz commented Nov 21, 2024

Uh oh!

zhangskz commented Nov 21, 2024

Uh oh!

jin commented Nov 22, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

acozzette commented Nov 26, 2024

Uh oh!

zhangskz commented Nov 26, 2024

Uh oh!

github-actions bot commented Mar 24, 2025

Uh oh!

github-actions bot commented Apr 8, 2025

Uh oh!

mbland commented Jun 13, 2025

Uh oh!

zhangskz commented Jun 13, 2025

Uh oh!

mbland commented Jun 13, 2025

Uh oh!

Uh oh!

jin commented Nov 5, 2024 •

edited

Loading

jin commented Nov 22, 2024 •

edited

Loading