* Fix plexus gav
* Install maven instead of just building it
The plugins need to be available in the local repo, else the build may download old snapshots
* Fix DefaultArtifactManager to allow using both Artifact and Dependency
* Add a TODO for an EventSpy related api
* Add simple string/model conversion on the XmlFactory
* Decouple services creation
* Move services to @Singleton scope
* Add protected constructors as builders should not be created directly
* Fix typos "can not" -> "cannot"
* Add some null checks on build(xx) shortcut methods
* Add a some missing conversion to immutable collections for requests
* [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>
# Conflicts:
# maven-core/src/main/java/org/apache/maven/lifecycle/internal/LifecycleModuleBuilder.java
# maven-core/src/main/java/org/apache/maven/session/scope/internal/SessionScope.java
To lessen mistake (copy-paste vs forgotten update) but also just to
make things less redundant. This also makes possible "experimenting"
much more easier.
This is merely a refactoring that does not takes or gives anything, just tidies up.
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.
Addendum to be2b7f890d98af20eb0753650b6605a68a97ac05:
* fix property name to align with existing ones
* fix logging configuration as no more shaded httpClient
* fix constant names
[DEBUG] Configuring mojo execution
'org.apache.maven.plugins:maven-surefire-plugin:3.0.0-M5:test:default-test'
with basic configurator
rephrase "Configuring" to "Loading" mojo "from plugin realm"
to differentiate from "configuring mojo" = apply configuration
rename populatePluginFields(..) private method
to populateMojoExecutionFields(..) to better match the intent
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).
As Resolver session contains non-MavenWorkspaceReader, the reactor models (already resolved w/ profiles applied) are re-built when using Resolver within Mojo, instead to get them via ReactorReader as expected. The rebuilt models will lack explicit (-P on CLI) profiles applied, as resolver itself is not maven aware, hence there is no way to "tell" resolver to apply them. Building reactor models w/ profiles applied is NOT done using resolver, but by Maven when loading up reactor, as profiles are NOT applied for downstream transitive dependencies (see discussion on MNG-1388 why).
Signed-off-by: Christoph Läubrich <christoph@laeubi-soft.de>
Co-authored-by: Christoph Läubrich <christoph@laeubi-soft.de>
Co-authored-by: Tamas Cservenak <tamas@cservenak.net>
Replace usage of
MavenExecutionRequest#getSelectedProjects()
by
MavenExecutionRequest#getProjectActivation().getOptionalActiveProjectSelectors()
Signed-off-by: Karsten Thoms <karsten.thoms@karakun.com>
This closes#664
Guillaume Nodet
Tamas Cservenak
Martin Kanters
Sylwester Lachiewicz
Giovanni van der Schelde
Michael Osipov
Hervé Boutemy
Marc Wrobel
Josef Cacek
Slawomir Jaranowski
Gabriel Belingueres
Karl Heinz Marbaise
Jacky
Maarten Mulders
Karsten Thoms