slachiewicz opened a new pull request, #158:
URL: https://github.com/apache/maven-reporting-exec/pull/158
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.
--
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]
