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
The artificial (or "bolted on") scope "import" behaves wildly differently that rest of Maven, causes surprise to our users. For start, we should emit "actionable" warnings about these, ultimate goal is to align this behaviour with "maven way" of working ("closest occurence wins" vs current weird "direct occurrence then first occurence wins" strategy).
Warnings are only created when the dependency is not directly managed. The warning also suggests to add a direct managed dependency to get rid of it, so it's now helpful and actionnable.
---
https://issues.apache.org/jira/browse/MNG-7854
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
* [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
* Add an InternalSession interface to avoid casting to the implementation in various places
* Upgrade to Guice 6.0.0 and add support for jakarta.inject annotations
* Maven 4 Plugin API
Even though this should not be supported, Maven 3.x is always using the 4.0.0 superpom. So if the version is not a supported model version, simply use 4.0.0. Any invalid value will be later verified by the model validator and eventually throw a meaninful exception.
It uses immutable list and while it suggests it allows this below, it actually fails on constructs like this (runtime ONLY):
{noformat}
new DefaultProfileSelector()
.addProfileActivator(new JdkVersionProfileActivator())
.addProfileActivator(new PropertyProfileActivator())
{noformat}
As default ctor creates immutable list, but API kinda suggests this is ok.
---
https://issues.apache.org/jira/browse/MNG-7910
The IT associated with this PR is using the Maven model to generate a hocon POM parser. This requires the maven-api-model module to attach the POM as an artifact, and the maven.yml change so that the model is present in the local repository.
Guillaume Nodet
Slawomir Jaranowski
Tamas Cservenak
Konrad Windszus
huazhongming
Hervé Boutemy