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
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
With some improvements. It accepts user property with CSV entries for relocations.
To toy with it, use `-Dmaven.relocations.entries` user property, for example create `.mvn/maven.config` file with contents:
```
-Dmaven.relocations.entries=entry1,entry2,...
```
It accepts CSV (comma delimited) of entries, while entry form is as:
```
GAV>GAV
```
Where left GAV can contain `*` for any elem (so `*:*:*` would mean ALL, something you don't want). Right GAV is either fully specified, or also can contain `*`, then it behaves as "ordinary relocation": the coordinate is preserved from relocated artifact. Finally, if right hand GAV is absent (line looks like "GAV>"). the left hand matching GAV is banned fully (from resolving).
Note: the ">" means project level, while ">>" means global (whole session level, so even plugins will get relocated artifacts) relocation.
Examples:
```
-Dmaven.relocations.entries=org.foo:*:*>,org.here:*:*>org.there:*:*,javax.inject:javax.inject:1>>jakarta.inject:jakarta.inject:1.0.5
```
Meaning: 3 entries, ban `org.foo` group (exactly, so `org.foo.bar` is allowed), relocate `org.here` to `org.there` and finally **globally relocate** (see ">>") `javax.inject:javax.inject:1` to `jakarta.inject:jakarta.inject:1.0.5`
---
https://issues.apache.org/jira/browse/MNG-7959
* [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
Tamas Cservenak
Slawomir Jaranowski
Guillaume Nodet
Martin Desruisseaux
Hervé Boutemy
huazhongming