[
https://issues.apache.org/jira/browse/MRESOLVER-512?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamas Cservenak updated MRESOLVER-512:
--------------------------------------
Description:
In Resolver 1.x times, resolver was unaware of "resolution scope", to get the
wanted resolution scope caller had to tweak and set up various nits and bits,
like selectors, filters, and so on. It was easy to miss. Similarly, resolver
had no "first class" type for "dependency scope" either, and its meaning and
notion was sprinkled across several classes. Introducing new scope in these
conditions (or alter selector to something that would have new scopes, like
Maven4 plans) was nearly impossible.
The ScopeManager aims to solve these issues: it defines "resolution scope" and
"dependency scope", interprets them, and allows caller to simply make a call to
"resolve me main-runtime" resolution scope. No hoops and loops. Moreover, it is
FASTER than Resolver 1.x was, that used always same selector (to build dirty
graph), so potentially huge graph even if you needed just a bit of it, that was
later chopped down to clean up the graph. ScopeManager automates selector
selection/setup, and goes directly for result, in most cases the resulting tree
is done in first pass.
Finally, and most importantly, ScopeManager allows to be "configured": by
supplying the recipe for dependency and resolution scopes, hence, makes
Resolver 2.x versatile, in a sense, it is not "this or that" anymore, it can
obey Maven3 and Maven4 dependency scopes at the same time.
was:Add centralized scope handling.
> Scope Manager
> -------------
>
> Key: MRESOLVER-512
> URL: https://issues.apache.org/jira/browse/MRESOLVER-512
> Project: Maven Resolver
> Issue Type: New Feature
> Components: Resolver
> Reporter: Tamas Cservenak
> Assignee: Tamas Cservenak
> Priority: Major
> Fix For: 2.0.0, 2.0.0-alpha-9
>
>
> In Resolver 1.x times, resolver was unaware of "resolution scope", to get the
> wanted resolution scope caller had to tweak and set up various nits and bits,
> like selectors, filters, and so on. It was easy to miss. Similarly, resolver
> had no "first class" type for "dependency scope" either, and its meaning and
> notion was sprinkled across several classes. Introducing new scope in these
> conditions (or alter selector to something that would have new scopes, like
> Maven4 plans) was nearly impossible.
> The ScopeManager aims to solve these issues: it defines "resolution scope"
> and "dependency scope", interprets them, and allows caller to simply make a
> call to "resolve me main-runtime" resolution scope. No hoops and loops.
> Moreover, it is FASTER than Resolver 1.x was, that used always same selector
> (to build dirty graph), so potentially huge graph even if you needed just a
> bit of it, that was later chopped down to clean up the graph. ScopeManager
> automates selector selection/setup, and goes directly for result, in most
> cases the resulting tree is done in first pass.
> Finally, and most importantly, ScopeManager allows to be "configured": by
> supplying the recipe for dependency and resolution scopes, hence, makes
> Resolver 2.x versatile, in a sense, it is not "this or that" anymore, it can
> obey Maven3 and Maven4 dependency scopes at the same time.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
