[ https://issues.apache.org/jira/browse/MNG-8163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17856703#comment-17856703 ]
Tamas Cservenak commented on MNG-8163: -------------------------------------- This stems how currently Resolver is architectured, and requires a bit of explanation. We briefly discussed with with [~gnodet] as well. Also, [~HannesWellmann] might be interested as well. As you know, Resolver by itself (artifacts produced by its build) is incomplete. Resolver lacks several component implementations that "completes" its object graph (Sisu components) and also lacks ANY model and so on, is done as "model agnostic" (Maven agnostic) on purpose. To make Resolver "complete" (as for its object graph and models), one need to supply more components and models (and semantics), see maven-resolver-provider module: it completes Resolver by providing the missing (in this case Maven specific) components and models. In short, Resolver must be "integrated" (with something) to make it usable, let's call it "integrator". Known integrators are things like Maven, MIMA or the supplier from Resolver itself (that, just like demos, pulls in resolver + maven bits), and they all provide different "levels of experience": Maven is, well "full Maven experience", MIMA is level lower (recognizes user Maven environment, interprets settings.xml, knows how to use plexus-sec-dispatcher.... ), it provides "like Maven env without full Maven". Finally, supplier experience (former ServiceLocator, that ALSO had to be extended as OOTB ServiceLocator from Resolver was incomplete) offers "basic experience": it can resolve, but is unaware of ANY Maven env bits, and user needs to set up everything manually, from location of local repo to auth, etc. So, this implies that, Resolver also have "several layers" of it's API as well: * "public api" for API consumers (like Mojos are in case of Maven): this is maven-resolver-api, spi and util * "integrator api" for integrators, they simply MUST reach in internals/guts to "complete" resolver * "internal" implementation This is somewhat documented here [https://maven.apache.org/resolver/api-compatibility.html] for "public api" consumers an here [https://maven.apache.org/resolver/third-party-integrations.html] for "integrators". All this above is "how things are", as in 2.0.0 cycle I did not had goal to rework all of this, I just continued on it. But I can understand (as I experienced with MIMA) how these things can be problematic on OSGi or JPMS. > MavenSessionBuilderSupplier depends on Resolver internal code > ------------------------------------------------------------- > > Key: MNG-8163 > URL: https://issues.apache.org/jira/browse/MNG-8163 > Project: Maven > Issue Type: Improvement > Reporter: Robert Scholte > Assignee: Tamas Cservenak > Priority: Major > > See current most recent tag: > https://github.com/apache/maven/blob/maven-4.0.0-beta-3/maven-api-impl/src/main/java/org/apache/maven/internal/impl/resolver/MavenSessionBuilderSupplier.java#L37-L42 > Once MRESOLVER-27 is in place I expect that these internal packages are not > accessible anymore (for those using the modulepath). -- This message was sent by Atlassian Jira (v8.20.10#820010)