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
Previously, to locate plugin configuration in a project the plugin descriptor
was read first and then 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 the relocation.
This closes#642
Revert "[MNG-7251] Fix threadLocalArtifactsHolder leaking into cloned project"
This reverts commit a6e462b53a.
Revert "[MNG-6843] Parallel build fails due to missing JAR artifacts in compilePath"
This reverts commit 73e00ed85d.
===
This closes#594
This PR introduce no API change, merely refactors MavenSession
getPluginContext method to truly thread-safe.
Also added Javadoc to affected field and method.
This constructor was deprecated in Maven 3.0-RC1 (!!!).
Removal also means that Maven4 will NOT work with
(Maven2 compatible) m-enforcer-p 2.x, only with
modern m-enforcer-p 3.x line.
This PR makes VersionScheme a component, is injected where needed
(instead of ad-hoc instantiation), but provides room for
different schemas, as GenericVersionScheme is "default"
but now nothing stops to add other schemes as well.
We had all kind of Loggers in Core, some Plexus
injected, some acquired using SLF4J LoggerFactory,
some static, some final, etc.
This PR aligns all those uses to SLF4J finals.
Notices:
* maven-core does NOT use Plexus Logger anymore
* did not touch maven-compat
Now that Plexus XMLs (and components) are out, no need
for this plugin in maven-core module anymore.
Changes:
* convert DefaultLifecyclePluginAnalyzer to JSR330 (last plexus component in core)
* drop dependency on plexus-component-annotations (note: it is still there but only as transitive dep of plexus-shim, needed to boot up Plexus Shim in tests)
* remove plexus-component-metadata plugin from build
* drop unused test Plexus XML
Maven Artifact Transfer silently prevents group level metadata to reach Resolver and causes metadata loss on install/deploy. Fix is to "bridge" this from maven-resolver-provider (and core) by reusing the actual metadata that m-plugin-p:addPluginArtifactMetadata mojo adds, but m-a-t filters out.
Gets rid of another set of Plexus components defined in XML.
Changes:
* DefaultArtifactHandler was declared as component but it is not needed; not
a component anymore
* Sanitize DefaultArtifactHandler class but retain Plexus XML provisioning
compatiblity (as plugins does have it declared in Plexus XML) and update its
uses within Maven code (be explicit)
* Use new "full" constructors in handler providers for easier comparison and
inspection (be explicit)
This closes#551
Since we have replaced the old JSR 250 library with javax.annotation library we
go straight to 1.3.2 because Maven Resolver 1.7.0 introduced this already as a
transitive dependency in fc806a25eb.
The only difference between version 1.2 and 1.3.2 is a Java upgrade from 6 to 8.
This closes#539
Both plexus-cipher and plexus-sec-dispatcher have had a
groupId change, but plexus-cipher change was implemented
for 1.8 version.
Latest versions of artifacts are 2.0. This PR
ups plexus-cipher version and adds proper changes
for plexus-sec-dispatcher groupId change.
This closes#534
Michael Osipov
Hervé Boutemy
Marc Wrobel
Josef Cacek
Tamas Cservenak
Guillaume Nodet
Slawomir Jaranowski
Giovanni van der Schelde
Gabriel Belingueres
Karl Heinz Marbaise
Jacky
Maarten Mulders
Karsten Thoms
Christoph Läubrich
Sylwester Lachiewicz
Martin Kanters
Falko Modler
Arturo Bernal
Guoxiong Li
George Gastaldi
Mickael Istria
rfscholte