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
* Add rootDirectory to XmlReaderRequest and fix maven-core exported artifacts
* Set the thread context classloader to the container realm to fix class loading from extensions
And ArtifactDescriptorReader should not "toss away" but report WARNings (as in case of ERROR or FATAL MB throws).
Part 1: port ArtifactDescriptorReader to not lose WARNs
Part 2: make model validator report Profile ID duplications even in MIN level (as model WARNs)
---
https://issues.apache.org/jira/browse/MNG-8141
If property `java.version` is in unexpected format, the activator throws `NumberFormatEx`, that in turn, is caught and reported by `DefaultProfileSelector` w/o any cause.
These should be cleanly reported instead: report that `java.version` property is in "unexpected format", and also report why was there are failure to evaluate a property activation.
Note 1: Maven allows `-Djava.version` override (!!!), this is exactly what IT MNG-3746 does, but the `NumberFormatEx` went unnoticed, was swallowed, no cause reported.
Note 2: This bug was revealed by #1555 as it reported the issue, and later "asserted error free log" which was not error-free. Hence, this bug was simply revealed by improved logging on unrelated issue.
---
https://issues.apache.org/jira/browse/MNG-8142
* 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.
Guillaume Nodet
Martin Desruisseaux
Jan-Jelle Kester
Tamas Cservenak
Slawomir Jaranowski
Michael Keppler
Hervé Boutemy
Matt Benson