Remove maven-compat, which needed three things rather than one

[slachiewicz]

Nothing here imports maven-compat, but removing it took three changes rather than one. The third is the interesting one.

1. The baseline

maven-core 3.6.3 ships DefaultProjectBuildingHelper with a field of the legacy org.apache.maven.repository.RepositorySystem, whose only implementation lives in maven-compat — so Mojo lookups fail without it. maven-core moved that field to MavenRepositorySystem in 3.9.12 exactly (commit 3afbdb8f76; git tag --contains gives maven-3.9.12, and the bytecode differs between 3.9.11 and 3.9.12). mavenVersion moves there, and resolverVersion to the 1.9.25 that Maven 3.9.12 itself ships, rather than a number chosen separately.

2. The local repository in the test

It was built through ArtifactRepositoryFactory, which exists only in maven-compat. MavenRepositorySystem.createArtifactRepository is a static method with the same five parameters, so only the receiver changes.

3. The part that is not visible from this project at all

After both of those, the tests still failed:

No implementation for RepositoryMetadataManager was bound.
  ... Unable to load the mojo 'test-javadoc' ... from the plugin
      org.apache.maven.plugins:maven-javadoc-plugin:3.4.0

The test loads maven-javadoc-plugin to exercise the executor, and pinned 3.4.0 — from 2022. That version needs RepositoryMetadataManager, whose interface is in maven-core but whose only implementation, DefaultRepositoryMetadataManager, is in maven-compat. So the removal was blocked by a component this project never mentions, reached through a plugin the test happens to load.

Current maven-javadoc-plugin does not use it, so the pin moves to 3.12.0.

Worth flagging for the wider effort: this is the same shape as the RepositorySystem problem — interface in maven-core, sole implementation in maven-compat — but it was not fixed in 3.9.12, so raising the baseline does not help with it. Anywhere a test loads an older plugin, that plugin's own compat needs become yours.

Verification

mvn verify: 4 tests, 0 failures — same as master. Run as verify rather than test deliberately: on a sibling project, removing maven-compat passed every test while breaking the build, because a dependency was arriving on the compile classpath through it and only the dependency analysis in verify catches that.

This raises the prerequisite

<prerequisites><maven>${mavenVersion}</maven></prerequisites> reads that property, so the minimum Maven for consumers goes from 3.6.3 to 3.9.12. That is a project decision — apache/maven#12709 is open to settle it across the plugins and shared components, with the survey data behind it. If the answer is "not yet", this should be closed and the dependency annotated as blocked rather than left looking like an oversight.

[Copilot]

Pull request overview

This PR removes the test-scoped maven-compat dependency by updating the project’s Maven/Resolver baselines and adjusting tests to use APIs available without maven-compat, including updating the pinned maven-javadoc-plugin used in tests.

Changes:

• Bump mavenVersion to 3.9.12 and align resolverVersion to 1.9.25, then remove org.apache.maven:maven-compat from test dependencies.
• Update the test’s local-repo construction to use MavenRepositorySystem.createArtifactRepository(...) instead of ArtifactRepositoryFactory.
• Update the test-pinned maven-javadoc-plugin from 3.4.0 to 3.12.0 to avoid maven-compat-only Plexus components.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.

File	Description
src/test/java/org/apache/maven/reporting/exec/TestDefaultMavenReportExecutor.java	Updates test setup to avoid maven-compat APIs and bumps the test-loaded javadoc plugin version.
pom.xml	Raises Maven/Resolver version properties and removes the test dependency on maven-compat.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.