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
Multiple optimizations :
- renderLevel() method use static constants instead of rebuilding the strings on each call
- replace + operator usage with more PrintStream.print() calls to reduce temporary strings creation
- reduce usage of MessageBuilder.a() method usage with more PrintStream.print() calls to reduce temporary strings creation
- replace the builder() method with a static import
- replace String.format with a simple string concat to reduce memory allocation (garbage)
- change static constants to class member in MavenSimpleLogger
- add a setLength(int) method in MessageBuilder to enable reuse
The purpose of the BOM packaging is to more cleanly identity POM that will be consumed as BOM from POM that will be used as parents. The BOMs can be turned into a consumer POM, whereas parents can not loose any information.
(that are not applicable, but look ugly).
These tests are NOT built, but are taken from real projects
several years ago, and used in POM related UTs.
Hence, for example update of velocity is completely okay,
even if in "real life" it would not compile.
This is most probably "just" about broken Throwable implementations.
Some override getCause but does not perform checks to what it was inited
as "this" means "not yet inited" actually.
---
https://issues.apache.org/jira/browse/MNG-7846
Changes:
* always parse it at session start
* hence, will WARN if needed there as well, and will warn once
* do not re-parse and possibly warn always, reuse parsed enum
---
https://issues.apache.org/jira/browse/MNG-7823
Given maven-shared-utils is being deprecated (see MSHARED-1269), we need to remove its usage in maven. Maven core only uses the logging/message related classes from maven-shared-utils, so this PR enhance the initial v4 api with the needed interfaces and move the jansi specific code into maven-embedder.
* Move maven-compat to jsr330
* Remove more ties to RepositorySystem
* Move more stuff to maven-compat
* Move PluginManager and LocalRepositoryNotAccessibleException to maven-compat
* Fix tests
* Break circular dependency loop in components
* Move unused deprecated classes
Checks the paths before relativizing them.
Normalize and relative before adding to result
Rename local vars
Apply to ExecutionEventLogger
---
https://issues.apache.org/jira/browse/MNG-7795
Co-authored-by: Andreas Dangel <adangel@apache.org>
Tamas Cservenak
Guillaume Nodet
huazhongming
Slawomir Jaranowski
Karl Heinz Marbaise
sebastien-doyon
Hervé Boutemy
Henning Schmiedehausen