slachiewicz opened a new issue, #12709:
URL: https://github.com/apache/maven/issues/12709
### 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:
- apache/maven-javadoc-plugin#1356 — 69 tests, 1 failure, identical to
master under the same command
- apache/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.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
