Declare Central as an origin of server central for Maven 3.10

[NassimBtk]

Problem

Since GitHub runner image ubuntu24/20261004 ships Maven 3.10.0, maven-central-deploy.yml fails at central-publishing:publish with HTTP Status: 401 on https://central.sonatype.com/repository/maven-snapshots.

Maven 3.10 scopes server credentials to the origins declared for their id (maven.repository.credentialScope=origin by default). The id central is bound to https://repo.maven.apache.org by the built-in central repository. The credentials of server central are therefore not sent to central.sonatype.com, and the log says so:

Not using credentials of server 'central' for repository https://central.sonatype.com: the origins declared for this id are [https://repo.maven.apache.org]

Change

After s4u/maven-settings-action, a step adds https://central.sonatype.com to the origins of server central in ~/.m2/settings.xml:

<repositoryOrigins><repositoryOrigin>https://central.sonatype.com</repositoryOrigin></repositoryOrigins>

• Why a separate step. s4u v4.0.0 cannot write <repositoryOrigins>. The step inserts the element after <server><id>central</id> and fails if the server is not found.
• What it covers. An origin is scheme://host[:port], so this covers both the release URL and the snapshots URL.
• Security. Origin scoping stays on. Unlike -Dmaven.repository.credentialScope=id, a repository named central at any other origin (declared by a dependency POM, for example) does not receive the publishing token. repo.maven.apache.org stays bound by the built-in central repository.
• Maven 3.9. It ignores the element with an "Unrecognised tag" warning, so runners still on the previous image keep working.
• Releases. Not affected: PublishMojo reads the server directly instead of going through the resolver's origin check.

This is an alternative to #35, which pins Maven 3.9.16. Maven 3.9.17 gets the same origin scoping, so pinning only delays the problem.

Validation

• I simulated an s4u v4.0.0 settings.xml (from its templates) and ran the step script exactly as YAML decodes it:

  • with server central: the element is inserted exactly once, inside that server;
  • without it: the step exits 1.

• I ran an end-to-end snapshot deploy of simple-http-java (central-publishing 0.11.0, profile maven-central) against a local server that behaves like Central: anonymous GETs allowed, and 401 with WWW-Authenticate: BASIC on anonymous PUTs. The origin was set to that server.

  Maven	Result
  3.10.0	BUILD SUCCESS, 31 authenticated requests, no 401, no "Not using credentials" warning
  3.9.12	BUILD SUCCESS, same output

• In CI, -Dmaven.repository.credentialScope=id already fixed simple-http-java and jflat on Maven 3.10.0, which confirms the cause.

Rollout

Callers pin a tag (@v6; some @v4 or @v2), so merging into main is not enough. After the merge, either:

• move v6 to the merge commit, or
• cut v7 and bump the callers.

Then remove mavenOptions: "-Dmaven.repository.credentialScope=id" from the callers that added it as a stopgap: simple-http-java and jflat (.github/workflows/deploy.yml).

metricshub-community has its own maven-build.yml; it gets the same step in MetricsHub/metricshub-community#1380.

🤖 Generated with Claude Code

[chatgpt-codex-connector]

Codex Review Summary

This comment shows the latest Codex review activity on this pull request.

Review	Status	Commit	Review trigger
📝 Code Review	✅ Completed 2026-10-08T15:45:41.142891Z	42b554c	PR opened

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.