Improve DefaultModelValidator.compareModelVersions to be able to compare
versions which different numbers of segments, allowing it to compare
"4", "4.0", and "4.0.0" to each other for example.
Signed-off-by: Craig Andrews <candrews@integralblue.com>
# Conflicts:
# maven-model-builder/src/test/java/org/apache/maven/model/validation/DefaultModelValidatorTest.java
Co-authored-by: Craig Andrews <candrews@integralblue.com>
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
Maven Consumer POM redone, it happens only in "maven3 realm" (before resolver), and allows use cases like m-gog-p and checksum-m-p work as before.
Key aspects:
* consumer POM is injected to build earliest possible as attached artifact
* it lives and is visible just like any other attached artifact (so m-gpg-p can process it)
* just before the install/deploy, they are "swapped out" to replace POM along with all "extras" it may have (checksum, signature)
* to support use cases like MNG-7067 (in memory model is changed, but not POM file), OnChangeTransformer could be extended to take into account both: file content and model content.
---
https://issues.apache.org/jira/browse/MNG-7622
* Clean a bit DefaultProfileActivationContext
* Cleanup DefaultProjectBuildingResult
* Cache the injected list to avoid repetitive lookups
* Lazily compute the MavenBuildTimestamp
* Use a single loop to select active profiles
