[jira] [Commented] (MRESOLVER-512) Scope Manager
[ https://issues.apache.org/jira/browse/MRESOLVER-512?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17831293#comment-17831293 ] ASF GitHub Bot commented on MRESOLVER-512: -- cstamas merged PR #445: URL: https://github.com/apache/maven-resolver/pull/445 > 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, they were just > string labels (that everyone knew HOW should behave, but was never codified) > 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)
[jira] [Commented] (MRESOLVER-512) Scope Manager
[ https://issues.apache.org/jira/browse/MRESOLVER-512?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17830123#comment-17830123 ] ASF GitHub Bot commented on MRESOLVER-512: -- cstamas commented on PR #1442: URL: https://github.com/apache/maven/pull/1442#issuecomment-2016563498 Added both scope manager config to maven4. IMO, when mvn4 builds mvn3 project (model Ver 4.0.0), it should use mvn3 scope manager, but when uses newer model, it should use mvn4 scope manager. > 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, they were just > string labels (that everyone knew HOW should behave, but was never codified) > 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)
[jira] [Commented] (MRESOLVER-512) Scope Manager
[ https://issues.apache.org/jira/browse/MRESOLVER-512?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17830117#comment-17830117 ] ASF GitHub Bot commented on MRESOLVER-512: -- cstamas commented on PR #445: URL: https://github.com/apache/maven-resolver/pull/445#issuecomment-2016560058 @gnodet applied changes, IMHO it looks even better now :smile: > 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, they were just > string labels (that everyone knew HOW should behave, but was never codified) > 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)
[jira] [Commented] (MRESOLVER-512) Scope Manager
[ https://issues.apache.org/jira/browse/MRESOLVER-512?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17830119#comment-17830119 ] ASF GitHub Bot commented on MRESOLVER-512: -- cstamas commented on PR #1442: URL: https://github.com/apache/maven/pull/1442#issuecomment-2016560169 @gnodet ported over changes happened in https://github.com/apache/maven-resolver/pull/445 : removal of system scope handler. > 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, they were just > string labels (that everyone knew HOW should behave, but was never codified) > 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)
[jira] [Commented] (MRESOLVER-512) Scope Manager
[ https://issues.apache.org/jira/browse/MRESOLVER-512?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17828649#comment-17828649 ] ASF GitHub Bot commented on MRESOLVER-512: -- gnodet commented on PR #445: URL: https://github.com/apache/maven-resolver/pull/445#issuecomment-2008977378 @cstamas The whole `SystemScopeHandler` needs has to be removed imho, it's superseded by the `ScopeManager`. > 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, they were just > string labels (that everyone knew HOW should behave, but was never codified) > 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)
[jira] [Commented] (MRESOLVER-512) Scope Manager
[ https://issues.apache.org/jira/browse/MRESOLVER-512?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17827555#comment-17827555 ] ASF GitHub Bot commented on MRESOLVER-512: -- cstamas commented on PR #445: URL: https://github.com/apache/maven-resolver/pull/445#issuecomment-246152 Well, IMO this PR goes exactly in direction of MRESOLVER-471, as: * scope manager is optional, in a sense, if you want to use Resolver 2.x as you did Resolver 1.x, go for it * ScopeManager solves the problem of "Resolver should be oblivious about scopes" (MRESOLVER-471), as Resolver 1.x implemented scope related logic scattered across several (dozen?) classes, and actions like "introducing new scope" or "removal of a scope" was impossible exactly due that (as Resolver was not oblivious, but had them cemented as String constants spread across dozen classes). Hence Resolver was "this xor that". With ScopeManager Resolver IS really oblivious, as they are defined by client project, the app that is integrating Resolver 2. > 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, they were just > string labels (that everyone knew HOW should behave, but was never codified) > 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)
[jira] [Commented] (MRESOLVER-512) Scope Manager
[ https://issues.apache.org/jira/browse/MRESOLVER-512?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17827539#comment-17827539 ] ASF GitHub Bot commented on MRESOLVER-512: -- cstamas opened a new pull request, #1442: URL: https://github.com/apache/maven/pull/1442 This makes all the new scopes implemented out of the box Related PR https://github.com/apache/maven-resolver/pull/445 --- https://issues.apache.org/jira/browse/MRESOLVER-512 > 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, they were just > string labels (that everyone knew HOW should behave, but was never codified) > 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)
[jira] [Commented] (MRESOLVER-512) Scope Manager
[ https://issues.apache.org/jira/browse/MRESOLVER-512?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17827498#comment-17827498 ] ASF GitHub Bot commented on MRESOLVER-512: -- gnodet commented on PR #445: URL: https://github.com/apache/maven-resolver/pull/445#issuecomment-1999632591 I'm *really* reluctant about this PR. This goes in the exact opposite direction than https://issues.apache.org/jira/browse/MRESOLVER-471, which aimed to make the resolver agnostic about scopes and leave these bits to be defined by Maven. It basically replaces 250 lines of deprecated code (the `JavaDependencyContextRefiner`, `JavaScopeDeriver` and `JavaScopeSelector` which were deprecated a few weeks ago) with 3800 new lines of code, adds a strong tie between the resolver and maven, whereas the code could be easily moved into maven which already exposes those concepts. > 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, they were just > string labels (that everyone knew HOW should behave, but was never codified) > 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)
[jira] [Commented] (MRESOLVER-512) Scope Manager
[ https://issues.apache.org/jira/browse/MRESOLVER-512?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17827486#comment-17827486 ] ASF GitHub Bot commented on MRESOLVER-512: -- cstamas opened a new pull request, #445: URL: https://github.com/apache/maven-resolver/pull/445 Resolver ScopeManager. --- https://issues.apache.org/jira/browse/MRESOLVER-512 > 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 > > > Add centralized scope handling. -- This message was sent by Atlassian Jira (v8.20.10#820010)
