Add googleapis and grpc-java #1699
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Hello @bazelbuild/bcr-maintainers, modules without existing maintainers (googleapis, grpc-java) have been updated in this PR. Please review the changes. |
keith
added
presubmit-auto-run
This was referenced Mar 27, 2024
Closed
This was referenced Mar 27, 2024
4 tasks
meteorcloudy
approved these changes
Mar 28, 2024
|
upstream prs are up:
but thanks for reviewing, either way we need this one first because of the circular dependency |
mbland
added a commit
to EngFlow/example
that referenced
this pull request
Apr 13, 2024
grpc-java only got MODULE.bazel support as of this most recent version: - grpc/grpc-java#11046 - bazelbuild/bazel-central-registry#1699 This grpc-java version bump exposed two issues that are fixed in this commit: 1. The //java/com/engflow/notificationqueue:client target dependency on @maven//:io_netty_netty_handler broke. The original WORKSPACE import of io_grpc_grpc_java imported this dependency directly by passing IO_GRPC_GRPC_JAVA_ARTIFACTS directly to `maven_install`. The `maven.install` call from grpc/grpc-java's MODULE.bazel sets `strict_visibility = True`. Somehow the other dependencies registered by grpc-java's MODULE.bazel are accessible to notificationqueue:client, but netty-handler isn't. The solution was to add the `io.netty:netty-handler:4.1.100.Final` artifact to the `maven.install` call in this project's MODULE.bazel. It doesn't seem an optimal solution, but it works for now. 2. grpc/grpc-java removed `io.grpc.stub.MetadataUtils.attachHeaders()` in grpc/grpc-java#10443. This caused notificationqueue:client to fail to compile, but that PR revealed the replacement for the deprecated `attachHeaders` call. This commit applies that replacement.
mbland
added a commit
to EngFlow/example
that referenced
this pull request
Apr 13, 2024
This appears to be a fairly recent development, and isn't yet 100% officially supported in the googleapis/googleapis repo, but it works: - googleapis/googleapis#855 - bazelbuild/bazel-central-registry#1699
mbland
added a commit
to EngFlow/example
that referenced
this pull request
Apr 15, 2024
* Enable bzlmod, update README, fix Swift build Rather than mess with the WORKSPACE rules, the shortest path to fixing `blaze build //swift:tests` appeared to be introducing MODULE.bazel. MODULE.bazel, a.k.a. bzlmod, appears to be the new hotness, so I'll also try updating the other builds to use it as well. - https://bazel.build/external/migration - https://bazel.build/external/overview#workspace-shortcomings - bazelbuild/bazel#18958 * Convert `bazel build //python/...` to MODULE.bazel * Convert `bazel build //csharp/...` to MODULE.bazel * Convert //go/..., gazelle to MODULE.bazel * Migrate protobuf, rules_proto to MODULE.bazel Also bumps to: - protobuf: 23.1 - rules_proto: 6.0.0-rc2 * Add rules_java, rules_jvm_external to MODULE.bazel rules_java was an implicit dependency before. Bumps: - rules_java: 7.4.0 => 7.5.0. - rules_jvm_external: 4.4.2 => 6.0 The rules_jvm_external docs describe using `maven.install` in MODULE.bazel as a replacement for `maven_install` in WORKSPACE: - https://github.com/bazelbuild/rules_jvm_external/blob/master/docs/bzlmod.md However, our current `maven_install` depends on the definition of IO_GRPC_GRPC_JAVA_ARTIFACTS from @io_grpc_grpc_java. I'll attempt that migration next. * MODULE.bazel: skylib, rules_proto_grpc, protobuf `bazel build //java/...` and `bazel test //java/...` both work with these changes. * Move grpc-java to MODULE.bazel, bump to 1.62.2 grpc-java only got MODULE.bazel support as of this most recent version: - grpc/grpc-java#11046 - bazelbuild/bazel-central-registry#1699 This grpc-java version bump exposed two issues that are fixed in this commit: 1. The //java/com/engflow/notificationqueue:client target dependency on @maven//:io_netty_netty_handler broke. The original WORKSPACE import of io_grpc_grpc_java imported this dependency directly by passing IO_GRPC_GRPC_JAVA_ARTIFACTS directly to `maven_install`. The `maven.install` call from grpc/grpc-java's MODULE.bazel sets `strict_visibility = True`. Somehow the other dependencies registered by grpc-java's MODULE.bazel are accessible to notificationqueue:client, but netty-handler isn't. The solution was to add the `io.netty:netty-handler:4.1.100.Final` artifact to the `maven.install` call in this project's MODULE.bazel. It doesn't seem an optimal solution, but it works for now. 2. grpc/grpc-java removed `io.grpc.stub.MetadataUtils.attachHeaders()` in grpc/grpc-java#10443. This caused notificationqueue:client to fail to compile, but that PR revealed the replacement for the deprecated `attachHeaders` call. This commit applies that replacement. * Move googleapis to MODULE.bazel This appears to be a fairly recent development, and isn't yet 100% officially supported in the googleapis/googleapis repo, but it works: - googleapis/googleapis#855 - bazelbuild/bazel-central-registry#1699 * Move rules_kotlin to MODULE.bazel, bump to v1.9.5 * Move rules_perl to MODULE.bazel, bump to 0.2.0 There's actually a 0.2.1 release, but it hasn't been pushed to https://registry.bazel.build/ yet. * Add rules_scala GitHub issue links rules_scala hasn't migrated to bzlmod yet, but discussion is underway. These links will help track its progress. * Migrate aspect_rules_ts to MODULE.bazel * Replace deps.bzl with go_deps This enables `bazel {build,test} //infra/...` to succeed using MODULE.bazel. See: - https://github.com/bazelbuild/rules_go/blob/master/docs/go/core/bzlmod.md#specifying-external-dependencies * Set test sizes to "small" as appropriate This eliminates warnings that these tests are sized too big, since the default is "medium". * Move http_{file,archive} calls to MODULE.bazel This moves the following http_file calls: - emacs - ubuntu_20.04_1.3GB and the following http_archive calls: - com_engflow_engflowapis - io_abseil_py * Update //platform rules, remove dotnet constraints The //dotnet/toolchain constraint was causing a Bazel error saying that the @@rules_dotnet//dontent/toolchain package didn't exist. Removing this constraint allowed remote execution to succeed anyway. * Update README, explain swift incompatibility Most of these changes are cosmetic, with the notable exception of the explantion behind the inability to build //swift remotely. Also added a `git` command to ignore python/requirements_lock.txt per: - https://stackoverflow.com/a/73720550
aiuto
pushed a commit
to aiuto/bazel-central-registry
that referenced
this pull request
Jun 3, 2024
These are in the same PR since they have a circular dependency on each other Fixes: bazelbuild#353 Fixes: bazelbuild#1113
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
These are in the same PR since they have a circular dependency on each other
Fixes: #353
Fixes: #1113