It seems Maven is eager to get POM from rootDirectory to support
CI Friendly versions. This change makes it "best effort", as in
if there is no POM, just walk away.
---
https://issues.apache.org/jira/browse/MNG-8288
* Sus method that nullifies model
* Make it clear
* Same change in new API
* Fix the logic to return the old value when unchanged
---------
Co-authored-by: Guillaume Nodet <gnodet@gmail.com>
With the introduction of the build pom and raw -> build pom transformation, the construction of the effective poms in two steps become very problematic. Over the time, multiple caches have been added to the ProjectBuilder and ModelBuilder related classes which are often redundant.
This PR thus changes things and move the recursive construction of the models fully into the ModelBuilder in a single call. When building build poms, a first step is done by parsing the file models from the root, then building all needed effective models from those. All the inference can be cleanly done because the builder has all the file models ready. The result will be used by the ProjectBuilder to build the projects.
During model building, we do not cache any hierarchy inheritance due to profiles that may be activated based on properties from the child projects.
So there's no way to cache the effective parent and just inject it into the child, the whole hierarchy need to be taken into account.
However, flattening the parent (i.e. inject the flattened parent's parent into the raw parent) should provide a parent model which has no parents anymore, not activated and not interpolated, but which can be cached and reused.
* Rename ArtifactCoordinate.getVersion() as getVersionConstraint().
* Introduce DownloadedArtifact, DownloadedDependency and ProducedArtifact.
* Rename coordinate -> coordinates.
* Add documentation on Artifact, ArtifactCoordinates, Dependency and DependencyCoordinates and other classes.
* Remove `LATEST` and `SNAPSHOT` from documentation since they are deprecated.
* Opportunistic addition of some missing `@Override` annotations.
---------
Co-authored-by: Martin Desruisseaux <martin.desruisseaux@geomatys.com>
* [MNG-7914] Provide a single entry point for configuration
* [MNG-7914] Rename global -> installation
* [MNG-7914] Include time zone in Maven build timestamp
* [MNG-7914] Use a single place to document all maven properties
As this is almost always source of confusion. If feature is used and there is no proper value set, fail the build, as users for sure does not plan to deploy artifacts with version `${revision}` (or any expression in project.version).
Still, to not be disruptive, the old behaviour can be achieved by setting `maven.build.allowExpressionInEffectiveProjectVersion`=true project property.
---
https://issues.apache.org/jira/browse/MNG-8211
Those methods are helpful for plugins that need to provide `--add-reads` and similar options,
as they allow to reuse the cached values instead of decoding `module-info.class` many times.
As they really can come from anywhere. In case of this issue even from some eliminated POM that was read while collecting dirty tree, and was later eliminated. So confusing for users.
---
https://issues.apache.org/jira/browse/MNG-8177
There was an NPE possibility when plugin.xml had no expected tags present.
Also: maven-compat has plugin.xml (!) w/o "name" tag, it NPEd and failed build. This was NOT picked up by CI as "rebuild itself" step does not install (just verify).
---
https://issues.apache.org/jira/browse/MNG-8180
* Use default classifier when Eclipse Aether specifies none.
The important change in this commit is in the implementation of `getClassifier()` methods.
However, this commit opportunistically refactors the code with a base class shared by `DefaultDependency` and `DefaultDependencyCoordinate` implementations.
* Preserve the type declared in the dependency (e.g. "modular-jar") when wrapping the object from Maven model.
Resolver handles transparently the repository metadata, and in case of plugins it peeks into META-INF/maven/plugin.xml of given artifact JAR to figure out needed metadata bits (prefix, name, etc).
But, this was done "blindly", while it is expected that GA of JAR artifact without classifier (requirement for maven plugins) and GA in embedded plugin metadata must be same.
Decision here is to fail hard, prevent this being installed and deployed, as this is most probably wrong (unsure what maven-indexer or even Sonatype search would do in this case).
---
https://issues.apache.org/jira/browse/MNG-8180
Guillaume Nodet
Tamas Cservenak
Hervé Boutemy
Martin Desruisseaux
Jan-Jelle Kester
Slawomir Jaranowski