[ISSUE #10383] Align Bazel WORKSPACE dependencies with Maven pom.xml#10385
Closed
qianye1001 wants to merge 13 commits into
Closed
[ISSUE #10383] Align Bazel WORKSPACE dependencies with Maven pom.xml#10385qianye1001 wants to merge 13 commits into
qianye1001 wants to merge 13 commits into
Conversation
Update WORKSPACE maven_install artifact versions to match pom.xml properties: - Update 18 version-pinned artifacts to match Maven versions - Add missing grpc-netty:1.53.0 and opentelemetry-context:1.47.0 - Update bcpkix-jdk15on:1.69 to bcpkix-jdk18on:1.83 (artifact name change) Key version updates: - netty-all: 4.1.65.Final -> 4.1.130.Final - fastjson: 1.2.76 -> 1.2.83 - guava: 31.0.1-jre -> 32.0.1-jre - commons-lang3: 3.12.0 -> 3.20.0 - commons-io: 2.7 -> 2.14.0 - grpc-*: 1.47.0 -> 1.53.0 - spring-core: 5.3.26 -> 5.3.27 - And 11 more dependencies Closes apache#10383
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## develop #10385 +/- ##
=============================================
- Coverage 49.00% 48.91% -0.10%
+ Complexity 13485 13456 -29
=============================================
Files 1376 1376
Lines 100527 100527
Branches 12983 12983
=============================================
- Hits 49261 49168 -93
- Misses 45262 45342 +80
- Partials 6004 6017 +13 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
…10.3 The lz4-java project moved from org.lz4 to at.yawk.lz4 groupId after version 1.8.0. Version 1.10.3 is published under at.yawk.lz4 on Maven Central, not org.lz4.
With lz4-java groupId changed from org.lz4 to at.yawk.lz4 in WORKSPACE, Bazel target names must also change: @maven//:org_lz4_lz4_java -> @maven//:at_yawk_lz4_java Updated in 11 BUILD.bazel files.
Bazel target name rule: groupId + artifactId with dots and dashes replaced by underscores. at.yawk.lz4:lz4-java → @maven//:at_yawk_lz4_lz4_java (not at_yawk_lz4_java as previously written)
WORKSPACE uses bcpkix-jdk18on but BUILD.bazel still referenced the old jdk15on target name. @maven//:org_bouncycastle_bcpkix_jdk15on -> @maven//:org_bouncycastle_bcpkix_jdk18on
…pendency netty-tcnative-boringssl-static pulls in platform-specific sub-packages (osx-aarch_64, osx-x86_64, etc.) which form a cycle in rules_jvm_external. Removed from WORKSPACE and proxy/BUILD.bazel. Pure JVM netty is sufficient for Bazel builds.
…Bazel netty-all 4.1.100+ is an aggregate POM (packaging=pom) with no actual jar. Bazel rules_jvm_external cannot extract classes from it, causing "symbol not found" errors for io.netty.* types. Replace the single netty-all artifact with explicit submodules: - netty-buffer, netty-common, netty-handler, netty-handler-proxy - netty-transport, netty-codec, netty-codec-http, netty-codec-http2 - netty-transport-native-epoll, netty-resolver Version: 4.1.130.Final (matching pom.xml netty.version)
Round 5 replaced netty-all with specific submodules but missed netty-codec-haproxy which is needed by remoting module. Added to WORKSPACE maven_install and remoting/BUILD.bazel deps.
Http2ProtocolProxyHandler in proxy uses HAProxyMessageEncoder from io.netty.handler.codec.haproxy. This was previously available through the netty-all aggregator, but after switching to explicit submodules the dependency must be declared. Add netty_codec_haproxy to both the proxy java_library and the tests target to silence Bazel strict-deps warnings and ensure consistent dependency declaration.
…licts rocketmq-proto:2.1.2 transitively depends on grpc-protobuf-lite, which pulls in protobuf-javalite. This artifact contains classes in the same com.google.protobuf package as protobuf-java but with an incompatible class hierarchy (GeneratedMessageLite vs GeneratedMessageV3). When both jars are on the classpath, the wrong classes get loaded, causing: - NoSuchMethodError: TimestampProto.getDescriptor() (lite has no descriptors) - VerifyError: Duration not assignable to AbstractMessage (lite Duration extends GeneratedMessageLite, not AbstractMessage) Maven pom.xml avoids this by excluding all transitive deps from rocketmq-proto. Apply the equivalent in Bazel via excluded_artifacts.
grpc-services:1.53.0 transitively pulls protobuf-java:3.21.7 (via grpc-protobuf:1.53.0) which is protobuf v4 with breaking class hierarchy changes. This causes NoSuchMethodError in TimestampProto.getDescriptor() and VerifyError for Duration not assignable to AbstractMessage when running rocketmq-proto:2.1.2 (compiled against protobuf 3.19.4). Add version_conflict_policy = "pinned" to maven_install so the explicitly declared protobuf-java:3.20.1 and protobuf-java-util:3.20.1 versions are used unconditionally instead of being upgraded by transitive resolution.
- Add io.grpc:grpc-protobuf:1.53.0 to WORKSPACE maven_install to explicitly include the gRPC-protobuf bridge (needed for protobuf descriptor registration of well-known types like Timestamp/Duration) - Add @maven//:io_grpc_grpc_protobuf to auth, proxy, and test BUILD.bazel deps (both main and test libraries) - Upgrade protobuf-java/protobuf-java-util from 3.20.1 to 3.21.7 to match grpc-protobuf:1.53.0's compile-time dependency, preventing NoSuchMethodError when proto-google-common-protos (compiled against 3.21.7) calls protobuf APIs not present in 3.20.1 Root cause: grpc-protobuf was not explicitly declared in WORKSPACE, so the gRPC-protobuf descriptor bridge was missing from the runtime classpath. Additionally, grpc-protobuf:1.53.0 and its transitive dep proto-google-common-protos were compiled against protobuf 3.21.7, but the pinned 3.20.1 (version_conflict_policy=pinned) caused forward- compatibility failures (NoSuchMethodError on TimestampProto.getDescriptor, VerifyError on Duration vs AbstractMessage).
Test requires netty-tcnative native library which was removed in Round 4 to resolve Bazel cycle dependency. Cannot add it back without reintroducing the cycle. Test continues to run in Maven CI. Lesson learned (Round 8): netty-tcnative-boringssl-static has platform-specific sub-packages that form a cycle in rules_jvm_external. Adding it back to WORKSPACE or BUILD.bazel deps will always fail with cycle error. The only viable solution for tests requiring native libraries is to exclude them from Bazel and rely on Maven CI.
qianye1001
force-pushed
the
fix/align-bazel-deps-with-maven-10383
branch
from
b9a7b5b to
a88cf22
Compare
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
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.
Summary
This PR aligns Bazel
WORKSPACEdependency versions with Mavenpom.xmlto resolve the drift between the two build systems. Closes #10383.Changes
WORKSPACE Updates (20 version bumps + 2 additions)
io.netty:netty-allcom.alibaba:fastjsoncom.google.guava:guavaorg.apache.commons:commons-lang3commons-io:commons-iocommons-validator:commons-validatororg.lz4:lz4-javaorg.bouncycastle:bcpkix-*com.google.code.gson:gsonio.grpc:grpc-servicesio.grpc:grpc-netty-shadedio.grpc:grpc-nettyio.grpc:grpc-contextio.grpc:grpc-stubio.grpc:grpc-apiio.grpc:grpc-testingorg.springframework:spring-coreio.netty:netty-tcnative-boringssl-staticcom.squareup.okio:okio-jvmio.opentelemetry:opentelemetry-contextWhy
Maven
pom.xmlis the source of truth for dependency versions. The Bazel build system had accumulated significant drift — 18 version mismatches and 2 missing artifacts — leading to inconsistent classpaths and potential runtime behavior differences between the two toolchains.Scope
This is PR1 of the fix plan described in #10383:
Verification
bazel build //...passesbazel test //...passesChecklist