This commit aims to complete d075fe7e85, which moved `ModelVersionParser`
interface from the `org.apache.maven.model.version` package to `org.apache.maven.api.services.model`.
Completing this change is necessary for building `maven-plugin-tools` or `maven-plugin-testing`.
This commit deletes the old interface for making sure that there is no accidental use.
The old and new interfaces were identical except for the package names and the imports.
As a result of this change, the following implementation classes are identical except
for package names and imports:
* `maven-resolver-provider/src/main/java/org/apache/maven/repository/internal/DefaultModelVersionParser.java`
* `maven-api-impl/src/main/java/org/apache/maven/internal/impl/DefaultModelVersionParser.java`
* 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.
These are dependency types to be used when dependency is "self contained", or is wanted be used as such: handle if like it has no dependencies, if any.
---
https://issues.apache.org/jira/browse/MNG-8089
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
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
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
With some improvements. It accepts user property with CSV entries for relocations.
To toy with it, use `-Dmaven.relocations.entries` user property, for example create `.mvn/maven.config` file with contents:
```
-Dmaven.relocations.entries=entry1,entry2,...
```
It accepts CSV (comma delimited) of entries, while entry form is as:
```
GAV>GAV
```
Where left GAV can contain `*` for any elem (so `*:*:*` would mean ALL, something you don't want). Right GAV is either fully specified, or also can contain `*`, then it behaves as "ordinary relocation": the coordinate is preserved from relocated artifact. Finally, if right hand GAV is absent (line looks like "GAV>"). the left hand matching GAV is banned fully (from resolving).
Note: the ">" means project level, while ">>" means global (whole session level, so even plugins will get relocated artifacts) relocation.
Examples:
```
-Dmaven.relocations.entries=org.foo:*:*>,org.here:*:*>org.there:*:*,javax.inject:javax.inject:1>>jakarta.inject:jakarta.inject:1.0.5
```
Meaning: 3 entries, ban `org.foo` group (exactly, so `org.foo.bar` is allowed), relocate `org.here` to `org.there` and finally **globally relocate** (see ">>") `javax.inject:javax.inject:1` to `jakarta.inject:jakarta.inject:1.0.5`
---
https://issues.apache.org/jira/browse/MNG-7959
* [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
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