[
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)
