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.
* 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>
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
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
This commit aims to complete d075fe7e85, which moved `ModelVersionParser`
interface from the `org.apache.maven.model.version` package to `org.apache.maven.api.services.model`.
Completing this change is necessary for building `maven-plugin-tools` or `maven-plugin-testing`.
This commit deletes the old interface for making sure that there is no accidental use.
The old and new interfaces were identical except for the package names and the imports.
As a result of this change, the following implementation classes are identical except
for package names and imports:
* `maven-resolver-provider/src/main/java/org/apache/maven/repository/internal/DefaultModelVersionParser.java`
* `maven-api-impl/src/main/java/org/apache/maven/internal/impl/DefaultModelVersionParser.java`
* Javadoc cleanup and replacement of some `System.getProperty("...")` by more specific standard methods.
* Add Type.PROCESSOR, MODULAR_PROCESSOR and CLASSPATH_PROCESSOR.
* Modification of the path type API:
* Add a `warningForFilenameBasedAutomodules()` method in `DependencyResolverResult`.
* Add relationships from `JavaPathType` to `javax.tool` location API.
* Modify the `PathType.option(Iterable<? extends Path>)` return type
because the option and the value need to be two separated arguments.
* Fixes according some comments on the pull request.
These are dependency types to be used when dependency is "self contained", or is wanted be used as such: handle if like it has no dependencies, if any.
---
https://issues.apache.org/jira/browse/MNG-8089
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
Update to Resolver 2.0.0-alpha-7, sort out TODO.
This is also one simple change "sneaked in" for RAT, to ignore local `.mvn` that is unrelated to all this, but does not make any harm. In turn, it allows dev local checkout to have various stuff set without
decorating those with headers or fighing RAT plugin.
---
https://issues.apache.org/jira/browse/MNG-8035
Maven should be fully in control regarding dependency scope definitions and their interpretations (and transformations).
This PR makes following changes:
* no change in behaviour (all works as before), but
* maven codebase contains now all the code related to scopes
* no resolver code is in use that was deprecated (as it was wrong to have it in resolver), see issue [MRESOLVER-471](https://issues.apache.org/jira/browse/MRESOLVER-471)
* this also stops scope definitions duplication as well, they are now defined in one single project: Maven
---
https://issues.apache.org/jira/browse/MNG-8026
Tamas Cservenak
Guillaume Nodet
Slawomir Jaranowski
Martin Desruisseaux
Hervé Boutemy
huazhongming