Currently there is some vague definition of a "build pom" versus a
"consumer pom":
https://maven.apache.org/studies/consumer-pom/https://cwiki.apache.org/confluence/display/MAVEN/Build+vs+Consumer+POM
there are also some plugins around to work with this e.g.
https://tycho.eclipseprojects.io/doc/latest/tycho-packaging-plugin/update-consumer-pom-mojo.htmlhttps://www.mojohaus.org/flatten-maven-plugin/plugin-info.html
but there are some issues:
Maven makes some assumptions about its "file", e.g setting the file
changes the basedir
Even though there is a setPomFile method that do not change the
basedir e.g. a parent ref by default would be broken
once we change the file, there is a mismatch between the pom on disk
and the model
it is not possible for a plugin to know the original file and the
consumer file, e.g. if I want to deploy the original file e.g. with
classifier "pom-build"
because of this usually "consumer pom plugins" generate the the new
pom to a new file in the project root, where it actually not belongs to
and leaves the file even after mvn clean if no special actions are
taken.
This enhance the MavenProject with one more method set/getConsumerPom
that fills this gap, then plugins working on the consumer pom can set
the file there and where it then is used by other plugins.
Both plugin and regular repository should have the same policy.
Unfortunately using "never" is not possible as long as resolver applies
this policy to both artifacts (immutable) and metadata (mutable)
It may lead to confusion as parameters (list) and
parametersMap (map) may "fall apart" easily.
Also, parametersMap did not honor parameter
ordering while parameters list makes it look
that order is important.
Simply, rebuild the map always and retain
ordering as well.
Added UT and also removed some cruft provided
by java8.
Co-authored-by: Marc Wrobel <marc.wrobel@gmail.com>
Co-authored-by: Slawomir Jaranowski <s.jaranowski@gmail.com>
(cherry picked from commit cc51006f29)
(cherry picked from commit 5ce5591ae3)
(cherry picked from commit 47e2d689d6)
---
https://issues.apache.org/jira/browse/MNG-7309
To version that supports gleaning JSR330 component classes up to Java 19. The reasoning of this change is only to allow 3rd party Maven plugins/Maven extensions/other JSR330 components (managed by Maven embedded Sisu) to use bytecode newer that Java 14 (Sisu 0.3.5), up to 19.
---
https://issues.apache.org/jira/browse/MNG-7913
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
Improve DefaultModelValidator.compareModelVersions to be able to compare
versions which different numbers of segments, allowing it to compare
"4", "4.0", and "4.0.0" to each other for example.
Signed-off-by: Craig Andrews <candrews@integralblue.com>
This is most probably "just" about broken Throwable implementations.
Some override getCause but does not perform checks to what it was inited
as "this" means "not yet inited" actually.
Backport of 36db1e35ca
---
https://issues.apache.org/jira/browse/MNG-7846
Changes:
* always parse it at session start
* hence, will WARN if needed there as well, and will warn once
* do not re-parse and possibly warn always, reuse parsed enum
---
https://issues.apache.org/jira/browse/MNG-7823
Update parent to 40. Also align plugin requirements with those from parent.
This lowers plugin validation "external" warnings from 12 to 3 (site, plexus-component-metadata and rat).
---
https://issues.apache.org/jira/browse/MNG-7816
Christoph Läubrich
Konrad Windszus
Hervé Boutemy
Tamas Cservenak
Slawomir Jaranowski
Craig Andrews
Bruno Volpato
Lenny Primak