commit | 39452f79bf406f31309dd167121e4a86e4796c93 | [log] [tgz] |
---|---|---|
author | Tamas Cservenak <tamas@cservenak.net> | Wed Mar 27 11:53:18 2024 +0100 |
committer | GitHub <noreply@github.com> | Wed Mar 27 11:53:18 2024 +0100 |
tree | 737673d1ed5ab0c233d7fbe2b61de1a84a4be0f4 | |
parent | 7d567a575a340e5b11271bc964181cfc7a26ac02 [diff] |
[MRESOLVER-512] ScopeManager (#445) 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. --- https://issues.apache.org/jira/browse/MRESOLVER-512
You have found a bug or you have an idea for a cool new feature? Contributing code is a great way to give something back to the open source community. Before you dig right into the code, there are a few guidelines that we need contributors to follow so that we can have a chance of keeping on top of things.
We accept Pull Requests via GitHub. The developer mailing list is the main channel of communication for contributors. There are some guidelines which will make applying PRs easier for us:
git diff --check
before committing.[MRESOLVER-XXX] - Subject of the JIRA Ticket Optional supplemental description.
mvn -Prun-its verify
to assure nothing else was accidentally broken.If you plan to contribute on a regular basis, please consider filing a contributor license agreement.
For changes of a trivial nature to comments and documentation, it is not always necessary to create a new ticket in JIRA. In this case, it is appropriate to start the first line of a commit with ‘(doc)’ instead of a ticket number.