* Javadoc cleanup and replacement of some `System.getProperty("...")` by more specific standard methods.
* Add Type.PROCESSOR, MODULAR_PROCESSOR and CLASSPATH_PROCESSOR.
* Modification of the path type API:
* Add a `warningForFilenameBasedAutomodules()` method in `DependencyResolverResult`.
* Add relationships from `JavaPathType` to `javax.tool` location API.
* Modify the `PathType.option(Iterable<? extends Path>)` return type
because the option and the value need to be two separated arguments.
* Fixes according some comments on the pull request.
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
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
Make Maven more friendly (and tunable) when ranges are being used. There new options are merely affecting range processing, allowing different narrowing strategies. Relies on latest Resolver alpha-6 features.
https://issues.apache.org/jira/browse/MNG-7960
This is an ongoing effort to confine Plexus, but also perform a bit of cleanup in Maven Core and around. No logic changes, just replacing Plexus with Lookup (that is a thin wrapper around it), and removing unused members, redundant checks, etc. Module maven-compat omitted on purpose.
---
https://issues.apache.org/jira/browse/MNG-7999
As it is actually not needed. This also "pulls in" all of VersionParser into model version parser, so Core implementation now 100% just delegates over there.
---
https://issues.apache.org/jira/browse/MNG-7978
Update to Resolver alpha-5 and apply some cleanups.
Notable changes:
* update resolver to 2.0.0-alpha-5
* detach model-builder from maven-artifact (this is important)
* introduce model builder own VersionParser iface (implemented in resolver-provider)
* API VersionParser implementation reuses VersionParser from resolver-provider to implement the service
* various other cleanups, removal of old plexus, etc
---
https://issues.apache.org/jira/browse/MNG-7974
* [MNG-7963] Clean up the build
Changes:
* remove hamcrest 1.3 from scope
* set proc:none to prevent warnings (Sisu APT is on classpath),
we do not use annotation processing, we produce Sisu index
explicitly.
* remove some redundant elements from POMs
Remove all ordering from Maven and delegate it to Resolver.
Supersedes https://github.com/apache/maven/pull/1212
This PR makes Maven completely rely on Resolver to order artifacts on classpath (before this PR it was several spots where explicit ordering was applied without ability to affect it). This PR makes now Maven completely rely on Resolver, never "sort" artifacts on it's own, but use resolver result, that in turn depends on session config.
Example invocation:
```
$ mvn -X package -Daether.system.dependencyVisitor=levelOrder
```
Would make Maven use "levelOrder".
Example of default (preOrder, as before) and new levelOlder (new in 2.0): notice how tree is same, but resulting artifact list (and hence, order on classpath) is different:
https://gist.github.com/cstamas/c88ca550006e53edad5b16973b54c349
The new resolver configuration is documented here:
https://maven.apache.org/resolver-archives/resolver-2.0.0-alpha-3/configuration.html
(property No 62)
---
https://issues.apache.org/jira/browse/MNG-7953
* Add an InternalSession interface to avoid casting to the implementation in various places
* Upgrade to Guice 6.0.0 and add support for jakarta.inject annotations
* Maven 4 Plugin API
Integrate better and obtain better control over Resolver. These changes did stem from "JPMS module experiment" and are considered improvement but does not implement any functionality related to JPMS module support.
Changes:
* Maven4 should stop "disconnected coexistence" of two type systems (ArtifactHandlers and Resolver ArtifactTypeRegistry), it should unify them.
* Maven4 Core should provide generic and extensible means to introduce new artifact types (fully in extension, and extension should get extended data via "roundtrip" in core/resolver)
---
https://issues.apache.org/jira/browse/MNG-7924
Upgrade to Resolver 2.0.0.
Changes:
* many UT code used `new DefaultRepositorySystem()` ctor that is gone (was present due SL only), replaced with mocks
* dropped MavenResolverModule Guice module (as AetherGuice module is gone as well)
* updated Resolver version to 2.0.0-alpha-1
* added jdk transport (that prevails apache on Java 11)
* rename of "native" into "apache", deprecate "native" name
* introduce "jdk" transport
---
https://issues.apache.org/jira/browse/MNG-7909
Martin Desruisseaux
Tamas Cservenak
Guillaume Nodet
Slawomir Jaranowski
Jonas Rutishauser
Hervé Boutemy
carrychair
huazhongming
Karl Heinz Marbaise