[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).
- Added warning when setting deprecated parameter with value different
than the default.
- Changed Logger to SLF4J.
(cherry picked from commit c99028b9fb67158edc9f202ff8a178c9465430ba)
The commit c604db3c3a103e2212f4628d8e2a997017fe579e
changed ReactorReader to use MavenSession#getAllProjects()
instead of deprecated MavenSession#getProjectMap() that
is equivalent of MavenSession#getProjects().
This undoes this unintended change.
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>
This adds support for property interpolation in extensions.xml to allow
advanced use cases where one wants to contribute certain things via the
commandline.
This closes#673
Previously, to locate plugin configuration in the project the plugin descriptor
was read and the GA were extracted. This always worked because the GA from the
model and the GA from plugin descriptor (plugin.xml) were identical. When a
plugin is relocated the target artifact is read, thus its plugin descriptor as
well. Naturally, the GA of new (relocated) does not correspond to the old
(static) one in the model. Therefore, the configuration is not found.
New approach is to use the original plugin GA to locate the configuration in
the model regardless of relocation.
VS Code creates directories with configurations in project directories. This
is usually fine, but triggers the `apache-rat` license alarms and future
VS Code users might accidentally commit the directory.
To solve the alarm and avoid future issues, we add it to .gitignore.
This closes#646
