Make execution flow never invoke path.toFile, at least what model-builder and maven-resolver-provider matters. Using new methods from Resolver 2 alpha8 and also adding in relevant maven bits, as half of the work was already done.
---
https://issues.apache.org/jira/browse/MNG-8059
Followup of MRESOLVER-484:
* move off deprecated resolver bits
* introduce non-deprecated replacements
* move existing to code to those new bits
---
https://issues.apache.org/jira/browse/MNG-8043
The artificial (or "bolted on") scope "import" behaves wildly differently that rest of Maven, causes surprise to our users. For start, we should emit "actionable" warnings about these, ultimate goal is to align this behaviour with "maven way" of working ("closest occurence wins" vs current weird "direct occurrence then first occurence wins" strategy).
Warnings are only created when the dependency is not directly managed. The warning also suggests to add a direct managed dependency to get rid of it, so it's now helpful and actionnable.
---
https://issues.apache.org/jira/browse/MNG-7854
Update to Resolver 2.0.0-alpha-7, sort out TODO.
This is also one simple change "sneaked in" for RAT, to ignore local `.mvn` that is unrelated to all this, but does not make any harm. In turn, it allows dev local checkout to have various stuff set without
decorating those with headers or fighing RAT plugin.
---
https://issues.apache.org/jira/browse/MNG-8035
Maven should be fully in control regarding dependency scope definitions and their interpretations (and transformations).
This PR makes following changes:
* no change in behaviour (all works as before), but
* maven codebase contains now all the code related to scopes
* no resolver code is in use that was deprecated (as it was wrong to have it in resolver), see issue [MRESOLVER-471](https://issues.apache.org/jira/browse/MRESOLVER-471)
* this also stops scope definitions duplication as well, they are now defined in one single project: Maven
---
https://issues.apache.org/jira/browse/MNG-8026
Introduce new method that returns POM and project Artifact in sensible manner (so install or deploy and other does not need to figure out anything).
Also, javadoc the class.
---
https://issues.apache.org/jira/browse/MNG-8023
Create _aether internal_ "extenders" components to serve several purposes:
* extender to meddle with exec request, for example to mediate between effective properties SPI (exec request extender)
* extender to meddle with prepped session and related bits, for example to move out deprecated code from session factory (session extender)
This PR implements M4 API SPI for contributing effective properties and exposes method for effective properties on `Session`.
* `Session` should expose properties service "ready" for interpolation, otherwise each interpolating code (plugin, etc) would need to construct the "effective" ones themselves, repeating same steps over and over again.
* SPI can contribute to user properties
* `Session` exposed properties are all immutable (sans effective, that is computed on each call).
* and lastly, a cleanup: all packages within `o.a.m.internal.aether` are now package protected, to tighten internal encapsulation. New core package `o.a.m.resolver` introduced that contains 2 publicly accessible classes.
---
https://issues.apache.org/jira/browse/MNG-8006https://issues.apache.org/jira/browse/MNG-8021
Maven4 seems sets but then drops/overrides some workspace readers. Partially due hazy borders who or what manages them, as role is split between session factory and session factory caller.
Changes:
* session factory does NOTHING re workspace readers, it becomes fully the caller duty
* two spots calling session factory (default maven, extension bootstrap) are now fully in charge to properly setup workspace readers
Co-authored-by: Jonas Rutishauser <jonas.rutishauser@alumni.ethz.ch>
---
https://issues.apache.org/jira/browse/MNG-8005
dependabot[bot]
Hervé Boutemy
Slawomir Jaranowski
Tamas Cservenak
Benjamin Marwell
Guillaume Nodet
Konrad Windszus
huazhongming