slachiewicz commented on issue #12709:
URL: https://github.com/apache/maven/issues/12709#issuecomment-5226573715
Tier 3 is now complete as three proposals, all verified with `mvn verify`
and none changing behaviour:
- apache/maven-javadoc-plugin#1356 — 69 tests, 1 failure, identical to master
- apache/maven-remote-resources-plugin#292 — 10 tests, 0 failures, identical
- apache/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.
--
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]
