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
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
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
* [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
* 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
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 IT associated with this PR is using the Maven model to generate a hocon POM parser. This requires the maven-api-model module to attach the POM as an artifact, and the maven.yml change so that the model is present in the local repository.
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.
This commit introduces three properties:
* project.rootDirectory: the project's directory or parent directory containing a .mvn subdirectory or a pom.xml flagged with the root="true" attribute. If no such directory can be found, accessing the rootDirectory property will throw an IllegalStateException.
* session.topDirectory : the directory of the topmost project being built, usually the current directory or the directory pointed at by the -f/--file command line argument. The topDirectory is similar to the executionRootDirectory property available on the session, but renamed to make it coherent with the new rootDirectory and to avoid using root in its name. The topDirectory property is computed by the CLI as the directory pointed at by the -f/--file command line argument, or the current directory if there's no such argument.
* session.rootDirectory : the rootDirectory for the topDirectory project.
The topDirectory and rootDirectory properties are made available on the MavenSession / Session and deprecate the executionRootDirectory and multiModuleProjectDirectory properties. The rootDirectory should never change for a given project and is thus made available for profile activation and model interpolation (without the project. prefix, similar to basedir). The goal is also to make the rootDirectory property also available during command line arguments interpolation.
A root boolean attribute is also added to the model to indicate that the project is the root project. This attribute is only supported if the buildconsumer feature is active and removed before the pom is installed or deployed. It can be used as an alternative mechanism to the .mvn directory.
* Split the header on two lines
* Properly delegates equals/hashCode to the v4 models
* Introduce object tracking in settings / toolchains
* Get back to a single template for v3 models
* Switch settings / toolchains mergers to deep merge
* Fix binary compatibility with 3.x
Something simple to use and would reuse all the auth/proxy etc data from Maven. Intentionally super-trivial API.
If something more "serious" needed, plugin should probably roll it's own solution.
---
https://issues.apache.org/jira/browse/MNG-7607
Guillaume Nodet
Tamas Cservenak
Hervé Boutemy
sebastien-doyon
Slawomir Jaranowski
huazhongming
Karl Heinz Marbaise
Piotrek Żygieło