-
-
Notifications
You must be signed in to change notification settings - Fork 260
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
Revert "Update rules_jvm_external to use the Starlark version of aar_import after the native version was removed from Bazel (#1149)" #1215
Revert "Update rules_jvm_external to use the Starlark version of aar_import after the native version was removed from Bazel (#1149)" #1215
Conversation
…import after the native version was removed from Bazel (bazel-contrib#1149)" This reverts commit ba7310c. The default label for AAR imports is `@rules_android//android:rules.bzl`. This imports `@rules_android//rules:providers.bzl`, which calls `@rules_android//rules/reexport_providers.bzl`. This means that any downstream user of `rules_jvm_external` with a sufficiently recent version of Bazel needs to add `build --experimental_google_legacy_api` to their `.bazelrc` That's a significantly breaking change, and one that it's not reasonable to ask our users to do, especially since the vast majority of projects don't use the Android rules.
cc @ahumesky |
This looks like bazelbuild/rules_android#219, and we probably cannot roll forward on this until we drop the dependency on that flag. |
To show this in action: git clone https://github.com/bazelbuild/rules_jvm_external.git
git clone https://github.com/bazel-contrib/rules_jvm.git
cd rules_jvm
bazel build //... --override_module=$(pwd)/../rules_jvm_external With the |
Sorry for the trouble, |
It happens, and I'm surprised it managed to slip through all the tests and checks. We know now, and we can fix things. Genuinely looking forwards to the time we can roll this forward again. Thank you for all your work making that happen! |
We've made significant progress on bazelbuild/rules_android#256 / bazelbuild/rules_android#219 Maybe this week or next we can try again with an updated version of ba7310c + updated version of rules_android |
I'd be happy to try it. Would be great to land this properly :) |
With bazel 7.4.0rc1 created today, I tested reapplying
|
We've been working to create rules_android version 0.6.0 this week and last, when that's out I'll resume getting all this committed again |
Since we're getting close(r) to a 0.6.0 release of rules_android, I tried my PR again with rules_android at head, and get some new errors. It looks like there are conflicting definitions of
leading to (at least):
|
Looks like there are some comments about the rules_jvm_external/MODULE.bazel Lines 152 to 156 in 534e62d
Latest rules_android needs to use the latest protobuf, so the android test targets (e.g. |
This seems to avoid the |
Regarding #1215 (comment) apparently I just needed to do |
I can get When I try bazel 6.5.0 with bzlmod, I get
So it looks like rules_jvm_external at head doesn't work with bazel 6.5.0 + bzlmod When I try it with workspace, I get a lot of problem with rules_android requiring things that aren't in bazel 6.5.0 (configuration fields, some things in |
This is fine. rules_jvm_external only supports bzlmod with Bazel 7+, not 6.5.0. We only support WORKSPACE with Bazel 6.5.0.
This works. |
This reverts commit ba7310c.
The default label for AAR imports is
@rules_android//android:rules.bzl
. This imports@rules_android//rules:providers.bzl
, which calls@rules_android//rules/reexport_providers.bzl
. This means that any downstream user ofrules_jvm_external
with a sufficiently recent version of Bazel needs to addbuild --experimental_google_legacy_api
to their.bazelrc
That's a significantly breaking change, and one that it's not reasonable to ask our users to do, especially since the vast majority of projects don't use the Android rules.