Do not depend on maven-resolver-supplier-mvn3 in maven-resolver-provider

[fridrich]

Following this checklist to help us incorporate your
contribution quickly and easily:

• Your pull request should address just one issue, without pulling in other changes.
• Write a pull request description that is detailed enough to understand what the pull request does, how, and why.
• Each commit in the pull request should have a meaningful subject line and body.
  Note that commits might be squashed by a maintainer on merge.
• Write unit tests that match behavioral changes, where the tests fail if the changes to the runtime are not applied.
  This may not always be possible but is a best-practice.
• Run mvn verify to make sure basic checks pass.
  A more thorough check will be performed on your pull request automatically.
• You have run the Core IT successfully.

If your pull request is about ~20 lines of code you don't need to sign an
Individual Contributor License Agreement if you are unsure
please ask on the developers list.

To make clear that you license your contribution under
the Apache License Version 2.0, January 2004
you have to acknowledge this by using the following check-box.

• I hereby declare this contribution to be licenced under the Apache License Version 2.0, January 2004
• In any other case, please file an Apache Individual Contributor License Agreement.

[fridrich]

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.

---

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

[maven-model-builder] (Maven)
        │
        ▼
[maven-resolver-provider] (Maven)
        │
        ▼
[maven-resolver-supplier-mvn3] (Resolver)
        │
        ▼
[maven-core] (Maven)

[fridrich]

I have another patch that would remove the dependency from maven-core by restoring back the maven-resolver-provider/src/main/java/org/apache/maven/repository/internal/MavenSessionBuilderSupplier.java the same way maven 4 keeps them. That would completely remove the cycle and the graph would be:

[maven-resolver]
    (core)
       │
       ▼
    [maven]
       │
       ▼
[maven-resolver-supplier-mvn3]

But this one would partially revert Tamas' commit 27f7b54 and I did not want to join the two together. Eventually, if you are opened towards it, I could submit as a follow-up PR. It lives currently in fridrich@98fe900

[cstamas]

@fridrich Thanks for working on this! I agree with your assessment, in fact, today I see as wrong decision of mine, when I placed "suppliers" into Resolver, they should go into Maven (as they are Maven version specific) in fact.

Longer story: supplier module was introduced in 1.9 (where ServiceLocator still exists), to provide simple transitioning for users of ServiceLocator, as explained on page https://maven.apache.org/resolver/third-party-integrations.html But today, for Resolver 2.x things got more complicated, and Resolver 2.x offering "mvn3 supplier" -- that is using 3.9.x classes makes things brrrr. I would really like to see some cleanup and sanitization in this area.

Ideally, maven-resolver (sans "demos", that are one plugin and some code that demonstrate "live resolver", there Maven classes are must) should not depend on Maven, and ideally maven-resolver-provider (with resolver JARs on classpath) should be able to bring up usable Resolver instance (object graph, either via Sisu or "manually" like suppliers did). And ideally, this should be sorted before 3.10 goes out. All in all, maven-resolver-provider pull in supplier was a bad decision. Maybe just copy-pasta the classes from supplier?

Note: when reverting/undoing 27f7b54 the "ADR decorator" should survive!

edit: created "counter PR" (reusing most of this PR) that I think is really what we want: #13266