[Java] Cease using `maven-release-plugin` due to its opinionated mutations of git history

[edburns]

High level rationale

Java’s Maven release is the only SDK publication process that treats releasing as a source-control mutation: it uses privileged automation to push multiple versioning commits and a tag directly to main before publication completes. Steve Sanderson questioned why the workflow must push directly to main instead of producing a PR, while Stephen Toub similarly objected to the direct push and asked whether it should be submitted as a PR. Their objections center on the branch-protection bypass, inconsistency with the other SDKs, and resulting failure and rollback complexity, favoring a PR-based or otherwise independently retryable CI publication flow.

Context

• The need for this work was first articulated by @SteveSandersonMS way back around 2026-05-14 in https://github.com/github/copilot-sdk-internal/issues/95 . At the time, we decided to allow the best practice for Java releases as encoded in maven-release-plugin to determine how we performed git tagging and versioning for the Java SDK. See this comment for the decision record. See also this slack thread.

• Further interaction with the need for this work happened in Request review of planned action #1873 . In particular, see this comment from @brunoborges: comment link. Also, teams link.

Job-to-be-done

Make the Java release pipeline a read-only consumer of the commit being released, consistent with the other language publishers. A Java release must derive its version from the shared release workflow, build and publish from an immutable source commit, and complete without committing to or otherwise modifying main.

The implementation must:

• Replace the use of maven-release-plugin and release:prepare with CI-friendly Maven versioning, using the version supplied by the release workflow only within the build workspace. No release or next-development version change may be committed to the repository.
• Update .github/workflows/java-publish-maven.yml so it checks out an explicitly resolved source SHA rather than creating a release commit and using a pre-publication java/vX.Y.Z tag as its source.
• Remove the documentation commit, the release-version commit, the next-SNAPSHOT commit, and every direct push to main from .github/workflows/java-publish-maven.yml. Documentation version updates must be made through the normal reviewed-PR process rather than as a side effect of publishing.
• Remove the JAVA_RELEASE_TOKEN preflight check, privileged checkout, contents: write requirement, and repository-ruleset bypass dependency. Maven Central and GPG credentials may remain because they authorize package publication rather than repository mutation.
• Remove the guarded rollback-release job and the commit/tag identity outputs that exist solely to undo partial release:prepare mutations. A failed publication must leave both main and repository tags unchanged.
• Preserve the existing cross-platform classifier builds, but ensure every classifier and the primary Java SDK artifact is built from the same immutable source SHA and receives the version calculated by .github/workflows/publish.yml.
• Update .github/workflows/publish.yml so publish-java follows the same contract as the other publishers: consume the shared version, build from the triggering SHA, publish the resulting artifacts, and report success without changing source-controlled files.
• Create the common vX.Y.Z GitHub release only after package publication succeeds. If a Java-specific java/vX.Y.Z traceability tag remains necessary, create it after successful publication, point it at the original release SHA, and manage it alongside the existing Go and Rust language tags in the github-release job rather than inside the Maven publication workflow.
• Retain an independently dispatchable Java publication path so a failed Maven Central deployment can be retried for the same version and source SHA without rerunning or altering the releases for other languages.
• Update .github/workflows/java-publish-snapshot.yml and the Java POM hierarchy as required by the new CI-friendly version mechanism, while preserving the snapshot workflow’s existing read-only relationship with the repository.

The work is complete when a successful or failed Java release creates no commits on main, requires no branch-protection bypass or elevated repository token, and publishes Maven artifacts whose version and source commit match the other SDK artifacts in the same release.

Internal User Story

dd-3061183-cease-maven-release-plugin