Describe the bug
The project maintains two parallel build systems — Maven (pom.xml) and Bazel (BUILD.bazel / WORKSPACE / MODULE.bazel). Over time the dependency graphs of the two have drifted: some artifacts present in Maven are missing, outdated, or differently versioned in Bazel, which leads to inconsistent classpaths, build failures on the Bazel path, and runtime behavior that differs between the two toolchains.
Current behavior
pom.xml declares dependencies / versions / scopes that are not reflected in the corresponding BUILD.bazel deps / runtime_deps / exports.- A few third-party libraries have been bumped in Maven but their
maven_install / rules_jvm_external pins in Bazel still point to older versions.
- New modules added under Maven do not yet have matching
java_library / java_binary targets, or the targets exist but reference a stale dep set.
- Some
provided / test scope mappings in Maven are not mirrored in Bazel (neverlink = True, testonly = True).
Expected behavior
Maven (pom.xml) is the source of truth. Bazel BUILD files and the external dependency lock should be regenerated/aligned so that:
- Every Maven dependency (same
group:artifact:version and scope semantics) is reachable from the equivalent Bazel target.
maven_install_json / lock file is regenerated and committed.- Per-module
BUILD.bazel deps lists exactly mirror the module's pom.xml <dependencies>, including provided → neverlink, test → testonly, optional → not exported.
bazel build //... and bazel test //... succeed and produce the same effective classpath as mvn -pl <module> dependency:tree.
Proposed scope of work
- Diff every module:
mvn dependency:tree vs bazel query 'deps(//module:target)', output a reconciliation table.
- Update
MODULE.bazel / WORKSPACE artifact list and regenerate the lock.
- Update each module's
BUILD.bazel deps / runtime_deps / exports to match.
- Add a CI check (script or Bazel test) that fails when
pom.xml and BUILD.bazel drift again.
- Document the alignment rule in the contributor guide so future PRs touching
pom.xml must also touch the matching BUILD.bazel.
Acceptance criteria
Describe the bug
The project maintains two parallel build systems — Maven (
pom.xml) and Bazel (BUILD.bazel/WORKSPACE/MODULE.bazel). Over time the dependency graphs of the two have drifted: some artifacts present in Maven are missing, outdated, or differently versioned in Bazel, which leads to inconsistent classpaths, build failures on the Bazel path, and runtime behavior that differs between the two toolchains.Current behavior
pom.xmldeclares dependencies / versions / scopes that are not reflected in the correspondingBUILD.bazeldeps/runtime_deps/exports.maven_install/rules_jvm_externalpins in Bazel still point to older versions.java_library/java_binarytargets, or the targets exist but reference a stale dep set.provided/testscope mappings in Maven are not mirrored in Bazel (neverlink = True,testonly = True).Expected behavior
Maven (
pom.xml) is the source of truth. Bazel BUILD files and the external dependency lock should be regenerated/aligned so that:group:artifact:versionand scope semantics) is reachable from the equivalent Bazel target.maven_install_json/ lock file is regenerated and committed.BUILD.bazeldepslists exactly mirror the module'spom.xml<dependencies>, includingprovided→neverlink,test→testonly,optional→ not exported.bazel build //...andbazel test //...succeed and produce the same effective classpath asmvn -pl <module> dependency:tree.Proposed scope of work
mvn dependency:treevsbazel query 'deps(//module:target)', output a reconciliation table.MODULE.bazel/WORKSPACEartifact list and regenerate the lock.BUILD.bazeldeps/runtime_deps/exportsto match.pom.xmlandBUILD.bazeldrift again.pom.xmlmust also touch the matchingBUILD.bazel.Acceptance criteria
bazel build //...greenbazel test //...green