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
Regular formatted stack traces do not have a space before the file/line
section.
before:
at java.util.zip.ZipFile$Source.get (ZipFile.java:1426)
after:
at java.util.zip.ZipFile$Source.get(ZipFile.java:1426)
* [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
Guillaume Nodet
Olivia Lucca Fraser
Karl Heinz Marbaise
Tamas Cservenak
dependabot[bot]
Michael Bien
huazhongming
Slawomir Jaranowski