[
https://issues.apache.org/jira/browse/MNG-8163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17856703#comment-17856703
]
Tamas Cservenak edited comment on MNG-8163 at 6/21/24 9:24 AM:
---------------------------------------------------------------
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, scope for resolver is really just a "label", integrator
assigns meaning to it, this can be seen in Maven4 and Resolver 2, resolver have
no scope at all, everything is deprecated), 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 examples of 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 was
incomplete) offers "minimal experience": provides you with working Resolver,
but is unaware of ANY Maven environment bits, and user needs to set up
everything manually, from location of local repo, repo authentication, use of
proxies, 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 are
the Resolver api, spi and util modules
* "integrator api" for integrators, they have to reach into internals of
Resolver to "complete" resolver
* and the rest as Resolver "internals"/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.
was (Author: cstamas):
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)
