[build] bump rules_jvm_external

[titusfortner]

💥 What does this PR do?

• bump rules_jvm_external to latest
• remove the publisher patch

🔧 Implementation Notes

If we run into another issue that requires that patch we want to debug and report upstream

[qodo-code-review]

Review Summary by Qodo

Upgrade rules_jvm_external to version 7.0

✨ Enhancement

Walkthroughs

Description

• Upgrade rules_jvm_external from 6.10 to 7.0
• Remove maven publisher patch no longer needed
• Simplify build configuration with upstream fix

Diagram

flowchart LR
  A["rules_jvm_external 6.10"] -- "upgrade" --> B["rules_jvm_external 7.0"]
  C["maven_publisher.patch"] -- "remove" --> D["no longer needed"]
  B --> E["Bazel 9 compatible"]

Loading

File Changes

1. MODULE.bazel Dependencies +1/-3

Update rules_jvm_external to 7.0

• Bump rules_jvm_external dependency from version 6.10 to 7.0
• Remove comment about Bazel 9 compatibility (now handled upstream)
• Remove rules_jvm_external_maven_publisher.patch from patches list
• Keep rules_jvm_external_javadoc.patch in patches list

MODULE.bazel

---

2. third_party/bazel/rules_jvm_external_maven_publisher.patch Dependencies +0/-32

Remove maven publisher patch file

• Delete entire patch file that was workaround for maven publisher issue
• Functionality now included in upstream rules_jvm_external 7.0

third_party/bazel/rules_jvm_external_maven_publisher.patch

---

[qodo-code-review]

Code Review by Qodo

🐞 Bugs (1) 📘 Rule violations (1)

1. Deleted third_party patch file 📘 Rule violation ⚙ Maintainability

Description

This PR deletes third_party/bazel/rules_jvm_external_maven_publisher.patch, which violates the
policy that third_party/ should be treated as read-only. Modifying vendored content can cause
dependency drift and noisy or unstable builds.

Code

third_party/bazel/rules_jvm_external_maven_publisher.patch[L1-32]

-diff --git a/private/tools/java/com/github/bazelbuild/rules_jvm_external/maven/MavenPublisher.java b/private/tools/java/com/github/bazelbuild/rules_jvm_external/maven/MavenPublisher.java
---- a/private/tools/java/com/github/bazelbuild/rules_jvm_external/maven/MavenPublisher.java
-+++ b/private/tools/java/com/github/bazelbuild/rules_jvm_external/maven/MavenPublisher.java
-@@ -174,16 +174,18 @@
-     Path pom = Paths.get(pomPath);
-
-     List<CompletableFuture<Void>> futures = new ArrayList<>();
-     futures.add(upload(repo, credentials, coords, ".pom", pom, signingMetadata, executor));
-
--    futures.add(
--        upload(
--            repo,
--            credentials,
--            coords,
--            "." + getFileExtension(mainArtifactPath),
--            Paths.get(mainArtifactPath),
--            signingMetadata,
--            executor));
--
-+    if (!mainArtifactPath.isEmpty()) {
-+      futures.add(
-+          upload(
-+              repo,
-+              credentials,
-+              coords,
-+              "." + getFileExtension(mainArtifactPath),
-+              Paths.get(mainArtifactPath),
-+              signingMetadata,
-+              executor));
-+    }
-+
-     if (!Strings.isNullOrEmpty(extraArtifacts)) {

Evidence

PR Compliance ID 3 forbids editing third_party/ contents. The diff shows the file
third_party/bazel/rules_jvm_external_maven_publisher.patch being deleted entirely in this PR.

AGENTS.md

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The PR deletes a file under `third_party/`, which is prohibited by the compliance checklist.

## Issue Context
Even if the patch is no longer referenced from `MODULE.bazel`, removing files from `third_party/` still constitutes modifying vendored content.

## Fix Focus Areas
- third_party/bazel/rules_jvm_external_maven_publisher.patch[1-32]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

2. BOM publish guard removed 🐞 Bug ☼ Reliability

Description

MODULE.bazel removes the local rules_jvm_external MavenPublisher patch that prevented uploading a
main artifact when the publisher is invoked with an empty main artifact path. Selenium’s release
pipeline includes BOM publish targets (e.g., :bom.publish and :bom-dependencies.publish), so if
rules_jvm_external 7.0 still produces an empty main artifact for POM-only publishes these release
steps can fail or upload the wrong path as the main artifact.

Code

MODULE.bazel[R45-51]

single_version_override(
    module_name = "rules_jvm_external",
    patch_strip = 1,
    patches = [
        "//third_party/bazel:rules_jvm_external_javadoc.patch",
-        "//third_party/bazel:rules_jvm_external_maven_publisher.patch",
    ],
)

Evidence

The PR removes the publisher patch from the rules_jvm_external override while the repo still has
explicit release targets that publish BOM artifacts, making the removed guard relevant to the
release pipeline’s maven_publish usage.

MODULE.bazel[33-51]
java/src/org/openqa/selenium/grid/BUILD.bazel[96-126]
rake_tasks/java.rake[7-31]
java/private/export.bzl[84-101]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
This PR removes the repository’s local patch that guarded MavenPublisher against an empty `mainArtifactPath`. The repo publishes BOM POMs as part of the Java release flow; those are commonly POM-only publishes and are exactly the scenario the removed guard was protecting.

## Issue Context
After bumping `rules_jvm_external` to 7.0, `MODULE.bazel` no longer applies `rules_jvm_external_maven_publisher.patch`. If upstream 7.0 doesn’t include the same guard, `bazel run //java/src/org/openqa/selenium/grid:bom.publish` and `...:bom-dependencies.publish` can regress.

## Fix Focus Areas
- MODULE.bazel[33-51]
- (Re-add) third_party/bazel/rules_jvm_external_maven_publisher.patch[new file]
- rake_tasks/java.rake[7-31]

## Concrete fix options
1) **If upstream 7.0 does NOT include the guard:** re-add the patch file (updated to apply cleanly to 7.0 sources if paths/line numbers changed) and reintroduce it in `single_version_override(... patches = [...])`.
2) **If upstream 7.0 DOES include the guard:** add a CI/release verification step (or at least document in the PR) that `//java/src/org/openqa/selenium/grid:bom.publish` and `:bom-dependencies.publish` succeed with 7.0, then consider removing the patch with that proof linked.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---