slachiewicz opened a new pull request, #292:
URL: https://github.com/apache/maven-remote-resources-plugin/pull/292
Nothing in the plugin imports anything from `maven-compat`. The declaration
was commented "needed in tests runtime" — true, but not because of this
plugin's code. Removing it alone does not work, and the reason is not in this
plugin.
### Why it could not simply be deleted
`maven-core` **3.6.3** ships `DefaultProjectBuildingHelper` with a field of
the legacy `org.apache.maven.repository.RepositorySystem`, whose only
implementation — `LegacyRepositorySystem` — 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`, which lives in maven-core
itself.
### The version is 3.9.12 exactly, not "3.9.x"
Worth being precise, since this sets a floor. Commit `3afbdb8f76` ("Use
MavenRepositorySystem in ProjectBuildingHelper instead of deprecated
RepositorySystem", #11358); `git tag --contains` gives `maven-3.9.12` as the
first release carrying it. Confirmed 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 `mavenVersion` moves to **3.9.12** — the earliest release where this
holds — rather than a rounder number that would raise the floor further than
necessary. `resolverVersion` moves to **1.9.25**, which is what Maven 3.9.12
itself ships, rather than a version chosen independently.
### This is a project decision, not just a refactor
`<prerequisites><maven>${mavenVersion}</maven></prerequisites>` reads that
property, so this **raises the minimum Maven for consumers from 3.6.3 to
3.9.12**. It wants a release-note entry and your agreement, not just a review
of the diff.
There is a legitimate alternative: **do nothing.** The dependency is
`test`-scoped, never ships, and costs users nothing. If the project is not
ready to move the floor, leaving it is defensible — but then the `@TODO
remove!!` should say so, rather than implying someone forgot. The precedent for
moving is `maven-plugin-plugin`, which removed its compat dependency in
MPLUGIN-519/520 by raising its prerequisite.
### Verification
`mvn verify`: **10 tests, 0 failures — identical to `master` under the same
command.** The suite is green on both sides.
Ran `verify` rather than `test` deliberately: on a sibling plugin, removing
maven-compat passed all tests while breaking the build, because a dependency
was reaching the compile classpath through it and only the dependency analysis
in `verify` catches that.
Part of a survey of which projects still declare `maven-compat` versus which
genuinely need it. This one needed only the baseline.
The dependency-analysis `<ignoredDependencies>` entry for maven-compat goes
at the same time.
--
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]
