Agree a minimum Maven baseline for the plugins and shared components

[slachiewicz]

Description

We have quietly ended up with a wide spread of minimum Maven versions across the plugins and shared components, and the stragglers are now costing us more than the compatibility they buy. This proposes agreeing a floor and moving the remainder to it.

Where we actually are

Counting the <mavenVersion> property across the plugin and shared repositories in a full local checkout — 65 projects declare one:

baseline	projects
3.9.16	31
4.0.0-rc-6	7
3.9.12	7
3.9.9 / 3.9.11 / 3.9.14 / 3.9.15	5
3.6.3	13
3.2.5	1 (shared/shared-utils)

So two thirds have already moved to 3.9.x or later, without anything being coordinated. The remaining fourteen are the outliers, not the norm.

Still on 3.6.3: maven-site-plugin, maven-changes-plugin, maven-checkstyle-plugin, maven-scm-publish-plugin, maven-stage-plugin, maven-scm-plugin, common-artifact-filters, dependency-tree, mapping, reporting-exec, shared-incremental, shared-io, shared-jar. Plus shared-utils on 3.2.5.

Why it is worth doing, concretely

The clearest cost is maven-compat. Several projects carry a test-scoped dependency on it while importing nothing from it — one of them with a @TODO remove!! on the line. It cannot simply be deleted, and the reason is not in the plugins:

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 any test that looks up a Mojo needing ProjectBuilder fails without it, with zero compat code in the plugin:

No implementation for org.apache.maven.repository.RepositorySystem was bound.
  while locating org.apache.maven.project.DefaultProjectBuildingHelper

maven-core changed that field to org.apache.maven.bridge.MavenRepositorySystem in 3.9.12 exactly — commit 3afbdb8f76, and git tag --contains gives maven-3.9.12 as the first release carrying it. Verified against the bytecode:

maven-core 3.9.11   org.apache.maven.repository.RepositorySystem repositorySystem
maven-core 3.9.12   org.apache.maven.bridge.MavenRepositorySystem repositorySystem

So for these projects, "remove maven-compat" and "raise the baseline to 3.9.12" are the same task. Two are proposed already, both verified with no behaviour change:

• Remove maven-compat by raising the Maven baseline to 3.9.12 maven-javadoc-plugin#1356 — 69 tests, 1 failure, identical to master under the same command
• Remove maven-compat by raising the Maven baseline to 3.9.12 maven-remote-resources-plugin#292 — 10 tests, 0 failures, identical to master

What a floor would settle

1. Which version. 3.9.12 is the lowest that solves the maven-compat problem. 3.9.16 is where most projects already are and would need no work for 31 of them. Either is defensible; picking one and writing it down is the point.
2. Whether it is per-project or a policy. <prerequisites><maven>${mavenVersion}</maven></prerequisites> means each bump is user-visible, so this is not purely internal.
3. What to do with the @TODO remove!! comments. Right now they imply someone forgot, when in fact the removal is blocked on a decision nobody has taken.

The honest counter-argument

For the maven-compat cases specifically, doing nothing is defensible. The dependency is test-scoped, never ships, and costs users nothing. If we are not ready to move the floor, that is a legitimate answer — but then the TODOs should say "blocked on baseline policy" rather than implying an oversight.

What is not defensible is the current state: fourteen projects sitting on a baseline the other fifty-one have already left, with no recorded reason.

Not in scope here

shared-utils at 3.2.5 and shared-io are separate conversations — a wider survey found shared-io's only remaining consumer in the tree is a single integration-test fixture, so its baseline may be moot.

[slachiewicz]

Tier 3 is now complete as three proposals, all verified with mvn verify and none changing behaviour:

• Remove maven-compat by raising the Maven baseline to 3.9.12 maven-javadoc-plugin#1356 — 69 tests, 1 failure, identical to master
• Remove maven-compat by raising the Maven baseline to 3.9.12 maven-remote-resources-plugin#292 — 10 tests, 0 failures, identical
• Remove maven-compat, which needed three things rather than one maven-reporting-exec#158 — 4 tests, 0 failures, identical

The third turned up something that changes the shape of this discussion. Raising the baseline was necessary but not sufficient there: the tests still failed with

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

RepositoryMetadataManager's interface is in maven-core, but its only implementation, DefaultRepositoryMetadataManager, is in maven-compat — the same shape as the RepositorySystem problem, and not fixed in 3.9.12. The blocker reached the project through a plugin its test happens to load, pinned at a 2022 version. Moving the pin to a current javadoc-plugin cleared it.

Two things follow for anyone else doing this:

1. A baseline bump alone will not always be enough. Where a test loads a third-party plugin, that plugin's own maven-compat needs become yours, and no change to your own baseline fixes it.
2. RepositorySystem is not the only interface-in-core/implementation-in-compat pair. Worth knowing before assuming 3.9.12 is a general answer — it solves DefaultProjectBuildingHelper specifically, not the pattern.