fridrich commented on PR #13259:
URL: https://github.com/apache/maven/pull/13259#issuecomment-5809190343
This change removes the dependency of `maven-resolver-provider` on
`org.apache.maven.resolver:maven-resolver-supplier-mvn3`, eliminating a
cross-repository circular dependency between Apache Maven and Apache Maven
Resolver.
### The Circular Dependency Cycle
* `maven-resolver-supplier-mvn3` (in Apache Maven Resolver) depends on
`org.apache.maven:maven-resolver-provider`.
* `maven-resolver-provider` (in Apache Maven) previously depended back on
`org.apache.maven.resolver:maven-resolver-supplier-mvn3`.
When Maven Resolver 2.0 dropped `DefaultServiceLocator` (MRESOLVER-157),
dummy stub interfaces for `Service` and `ServiceLocator` were retained in
`maven-resolver-supplier-mvn3` strictly as transitional shims.
`MavenRepositorySystemUtils.newServiceLocator()` was subsequently removed from
Maven in commit `e04f0bd1db`.
Because internal classes (`DefaultArtifactDescriptorReader`,
`DefaultVersionResolver`, and `DefaultVersionRangeResolver`) still implemented
`Service` and `initService(ServiceLocator)`, `maven-resolver-provider` was
forced to retain its dependency on `maven-resolver-supplier-mvn3`. This cycle
breaks clean-room builds, source bootstrapping, and Linux distribution
packaging (e.g., openSUSE, Fedora, Debian) that rebuild the entire stack from
source in a single pass.
---
## Proposed Changes
1. **Remove POM Dependency**: Drop `maven-resolver-supplier-mvn3` from
`maven-resolver-provider/pom.xml`.
2. **Remove Orphaned Lifecycle Hooks**: Remove `implements Service` and the
deprecated `initService(ServiceLocator)` methods from
`DefaultArtifactDescriptorReader`, `DefaultVersionResolver`, and
`DefaultVersionRangeResolver`. This aligns with upstream Resolver 2.x
components (e.g., `BasicRepositoryConnectorFactory`), which dropped `Service`
support in the same manner.
3. **Remove Redundant Unit Tests**: Remove `MavenRepositorySystemUtilsTest`
(including `#testGetRepositorySystem` and `#testGetMetadataGeneratorFactories`).
---
## Impact & Compatibility Analysis
* **Does it break ServiceLocator?** No. `DefaultServiceLocator` was deleted
in Resolver 2.0.0, and the `Service` interface in Resolver 2.x is an empty
stub. No code in Resolver 2.x or Maven calls `initService(ServiceLocator)`.
* **Does it break `RepositorySystemSupplier`?** No.
`RepositorySystemSupplier` wires `maven-resolver-provider` components via
explicit constructor injection (3-arg and 7-arg constructors) and never invokes
`initService()` or casts components to `Service`.
* **Does it break Maven runtime (CLI & `maven-core`)?** No. Maven uses
Sisu/Plexus DI with `@Inject` constructors and `@Named` annotations, which
never rely on `ServiceLocator`. `maven-core` retains its direct dependency on
`maven-resolver-supplier-mvn3` for `SessionBuilderSupplier`.
* **Does it break public API or ABI?** No. Public interfaces
(`ArtifactDescriptorReader`, `VersionResolver`, `VersionRangeResolver`) remain
unmodified. The modified classes reside in internal implementation packages
(`org.apache.maven.repository.internal.*`).
* **Does it affect external embedders?** No. Legacy embedders using
`DefaultServiceLocator` were already broken when moving to Resolver 2.x / Maven
3.10. Modern embedders use Sisu/Guice injection or `RepositorySystemSupplier`,
which wires via constructors.
* **Does removing `MavenRepositorySystemUtilsTest` reduce coverage?** No.
The removed test only asserted that `new RepositorySystemSupplier().get()`
returned a non-null result. The supplier functionality is covered more
thoroughly upstream by `RepositorySystemSupplierTest#smoke()` in
`apache/maven-resolver`. Real session creation via
`MavenRepositorySystemUtils.newSession()` remains covered across
`maven-resolver-provider` by `AbstractRepositoryTest` and its subclasses.
---
## Resulting Dependency Graph
```text
[maven-model-builder] (Maven)
│
▼
[maven-resolver-provider] (Maven)
│
▼
[maven-resolver-supplier-mvn3] (Resolver)
│
▼
[maven-core] (Maven)
```
--
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]
