In short: do NOT set request.setRawModel as NOTHING sets it. The Maven4 vs Maven3 is different, in Maven 3 NOTHING calls request.setRawModel
Full explanation: as ModelBuildingRequest is REUSED, and nothing sets this value in Maven3, once you set it here (as in original PR https://github.com/apache/maven/pull/849 ) results in awkward situation in Maven3: it will not load any other model...
---
https://issues.apache.org/jira/browse/MNG-6609
LocalRepositoryManager needs configurations from RepositorySystemSession
so must be created after session configuration is finished.
(cherry picked from commit b1c1f7556d)
chery-pick from a6b1ebb1cd
Old actions use deprecated node 12
- cache v2 -> v3
- checkout v2 -> v3
- download-artifact v2 -> v3
- setup-java v2 -> v3
- disable access to GITHUB_TOKEN
- don't store credentials with checkout
- don't execute build for PR from local repository branches - we have build on push event
* Make sure RAT plugin ignores files in the target folder
* Fix gitignore so that it can work with rat, do not inherit execution in children, use a single place to configure rat
* Exclude .asf.yaml from rat check
* Add repo/ to the .gitignore file as it's often used for local repository
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).
* [MNG-7474] SessionScoped beans should be singletons for a given session
Now that the Session is not cloned anymore, we can revert to the original
(Maven < 3.3) behavior of the session scoped components.
Co-authored-by: Christoph Läubrich <christoph@laeubi-soft.de>
This closes#743
* Remove setting a value which is the default already
Co-authored-by: Christoph Läubrich <christoph@laeubi-soft.de>
Instead of user properties, as this allows making "permanent" the
selection by using MAVEN_OPTS and other places as well. Currently
only via command line works.
Also, do not modify existing Maven behavior, so introduce "default" branch
in selection. See comment in code
Problem: resolver spi, impl and connector-basic has changes in 1.8.0 (SPI interface RepositoryLayout got new method, that is implemented in connector-basic, and code from impl is using it). But, Maven core exports only resolver api, spi and impl packages, while the rest is at mercy of a plugin. This means ,that these artifacts (api, spi and impl) will always come from Maven core, whatever version plugin declares, while the "rest" (connector-basic and util) will be of version that plugin declares. The current state hence prevented ANY KIND of changes on SPI interfaces that would be implemented in connector-basic (which is the case in Resolver 1.8.0).
Solution: make all these resolver artifacts "provided" (to behave like maven-core or maven-plugin-api is behaving): simply put, whatever resolver artifact plugin depends on, it should NOT use it's own version, but the version from Maven. This ensures that api-spi-impl-connector-basic as "aligned" and are same version.
Details:
The change is to make util is exportedArtifact AND exportedPackage, while connector-basic is only exportedArtifact.
Reasoning:
* exportedArtifact -- prevents "own" artifact to be added to realm
* exportedPackage -- makes it "visible" in realm
So, this basically prevents bad versions of util and connector-basic
enter the plugin realm (as they will be not added to it), while
util remains "visible" to plugins, as the intent was, most
common due GenericVersions etc.
This change also results in simpler expectations to plugin developers:
resolver libraries should really behave like maven-core or maven-compat:
when plugin declares dependency on these (w/ scope provided as best
practice), they really get version of these that are of version that
maven runs in, not version they declare. So same thing happens now with
resolver: you will get same version of resolver that maven uses your plugin
runs in.
Before this change, it was a mixed bag: api, spi and impl was from maven,
while util and connector-basic was version you pulled in as dep.
Tamas Cservenak
Konrad Windszus
Slawomir Jaranowski
Piotrek Żygieło
Abdel Hajou
Michael Osipov
Guillaume Nodet
Sylwester Lachiewicz
Henning Schmiedehausen
Hervé Boutemy
Josef Cacek
Rafael Chaves
Karl Heinz Marbaise