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
* [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
Even though this should not be supported, Maven 3.x is always using the 4.0.0 superpom. So if the version is not a supported model version, simply use 4.0.0. Any invalid value will be later verified by the model validator and eventually throw a meaninful exception.
It uses immutable list and while it suggests it allows this below, it actually fails on constructs like this (runtime ONLY):
{noformat}
new DefaultProfileSelector()
.addProfileActivator(new JdkVersionProfileActivator())
.addProfileActivator(new PropertyProfileActivator())
{noformat}
As default ctor creates immutable list, but API kinda suggests this is ok.
---
https://issues.apache.org/jira/browse/MNG-7910
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.
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
* Fix plexus gav
* Install maven instead of just building it
The plugins need to be available in the local repo, else the build may download old snapshots
Tamas Cservenak
Guillaume Nodet
Slawomir Jaranowski
Elliotte Rusty Harold
Tim te Beek
Karl Heinz Marbaise
Andrey Bruykhov
Michael Osipov
Hervé Boutemy
Pavel Horal
Konrad Windszus
Sylwester Lachiewicz
Marc Wrobel
Giovanni van der Schelde
Arturo Bernal
Christoph Läubrich