Build: drop the retired sonatype-public-repository plugin repository

[delchev]

The failure

The nightly samples shard on H2 (run 33142663391) died after 2.8 s — before a single test ran:

[ERROR] Plugin org.apache.maven.plugins:maven-install-plugin:3.1.4 or one of its
dependencies could not be resolved: Could not transfer artifact ... from/to
sonatype-public-repository
(https://ossrh-staging-api.central.sonatype.com/content/groups/public):
status code: 400, reason phrase: Bad Request (400)

The endpoint is retired

Every path under that group answers 400 with an explicit message — the root, maven-metadata.xml, and any artifact alike:

$ curl .../content/groups/public/org/apache/maven/plugins/maven-install-plugin/3.1.4/maven-install-plugin-3.1.4.pom
400
Endpoint /content/groups/public/... not supported. Please contact Central Support (central-support@sonatype.com)

The same POM is 200 from repo1.maven.org.

Why it takes the build down

sonatype-public-repository was the only entry in <pluginRepositories>, so it was consulted ahead of Central for every plugin the build resolves. The <repositories> block directly above it already points ossrh at repo1.maven.org — the plugin repository was simply left behind on the dead Nexus-style path.

Only one of the eight nightly shards failed because the other seven restored a Maven cache that already held maven-install-plugin:3.1.4 and never hit the network for it. Any shard whose cache misses a plugin fails, so this is flaky-by-cache: a pom.xml change invalidating the hashFiles('**/pom.xml') cache key would have taken the whole matrix down at once.

The fix

Delete the block. The OSSRH public group was a proxy of Central plus staging snapshots, and <snapshots> was already disabled here, so it never served a coordinate Central does not — Central (implicit from the super-POM) covers every plugin the build uses.

Verification

Full-reactor mvn dependency:resolve-plugins against an empty local repository, with the block removed:

• BUILD SUCCESS, all modules
• 551 artifacts downloaded
• every request went to repo.maven.apache.org or repo1.maven.org; zero to ossrh-staging-api

Out of scope, but worth a look

<distributionManagement> still uses the same host for snapshots (/content/repositories/snapshots) and staging deploys. Releases go through central-publishing-maven-plugin with extensions=true, which supplies its own deploy path, so the release train is probably unaffected — but a plain mvn deploy of a SNAPSHOT would hit the same retired /content/ prefix. Left untouched here to keep this change to the one line of breakage that is proven.