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
Just warn for now, we cannot go from builds-ok w/
3.9.8 to fails-the-build in 3.9.9. Warning
can raise awareness, and this pattern is bad as
it is, but users now become aware that they may
have rogue plugin.xml (just like maven-compat had).
The original bug is fixed (Maven deploys unrelated metadata).
Same change is to be ported to master as well.
---
https://issues.apache.org/jira/browse/MNG-8180
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
Fix and improvement in one PR as they are closely related.
First, this PR restores the ability (broken by MNG-8081) to calculate Profile activation for POMs with duplicate Profile ID.
Second, this PR improves UX by warning them about invalid models in their build.
The reproducer now looks like this:
https://gist.github.com/cstamas/165a610b233f4c03e381a0a2697903eb
Notice:
* WARNs issued about models (all Maven versions are mute about this)
* still, property `${javafx.platform}` properly evaluated just like in 3.9.6 (but not in 3.9.7)
* build succeeds (fails in 3.9.7)
---
https://issues.apache.org/jira/browse/MNG-8147https://issues.apache.org/jira/browse/MNG-8141
Maven Resolver Provider gets similar change as other Resolver components had in MRESOLVER-386.
Also, some minor code updates like adding Override and other cosmetic stuff.
---
https://issues.apache.org/jira/browse/MNG-7856
Structure the version checks slightly different to make the separation
between repository versions and the version range resolution clearer.
Backport from master branch
Ensure that any versions resolved as part of a version range request
only reference repositories that are actually enabled for the type of
version (SNAPSHOT versions against snapshot repos, release versions
against release repositories).
Maven Artifact Transfer silently prevents group level metadata to reach Resolver and causes metadata loss on install/deploy.
Fix is to "bridge" this from maven-resolver-provider (and core) by reusing the actual metadata that
m-plugin-p:addPluginArtifactMetadata mojo adds, but m-a-t filters out.
This is backport of commit d141957ff5 from master to maven-3.9.x branch.
But keep Wagon as default transport. This PR merely includes
resolver http and file transport and switches wagon-http
to non-shaded one.
Changes:
* switch to non-shaded wagon-http (as httpClient is now shared)
* include resolver http and file transport
* override resolver default behaviour (native transport preferred over wagon, when both on classpath)
* provide simplistic means to choose transport
The chosen transport can be seen in debug (-X) output on line
`[DEBUG] Using transporter XXX...`
The `-Dmaven.transport` simplistic switch can be used to choose transport:
* not set: default, that is Wagon
* `wagon`: explicitly sets Wagon
* `resolver`: explicitly sets resolver native transports (file and http)
* `auto`: relies on resolver "auto discovery" (priorities, etc). This is MUST to keep transport pluggable with 3rd party transports. In fact, this was the default so far in Maven, along with the fact that native resolver transports were not included (as resolver prefers native ones over Wagon).
Tamas Cservenak
Slawomir Jaranowski
Hervé Boutemy
Andrey Bruykhov
Michael Osipov
Slawomir Jaranowski
Konrad Windszus
Sylwester Lachiewicz
Henning Schmiedehausen