[EXPERIMENT] Resolver locking mode set from Maven#761
Closed
[EXPERIMENT] Resolver locking mode set from Maven#761
Conversation
if attached artifacts already contains the artifact remove it and add the new one Signed-off-by: olivier lamy <olamy@apache.org>
The plugin key is build as combination of artifactId and groupId but not updated if either of these two ids change. This can be a problem if artifactId or groupId is a variable. The calculated key will likely contain the unresolved property and is not updated once the variable is interpolated. This closes #372
… dependencies This closes #311
This fixes following bug and also consistent with another 'cd /d "%EXEC_DIR%"' a few lines above. When you're on the root of some disk running mvn.cmd prints an extra line with current dir before the correct output Closes #304
Don't compare baseDir in a canonical form when the second comparing value (System.getProperty( "user.dir" )) is not canonicalized. This closes #361
…lified on Windows The removed 'stripMHome' recursive function is not needed anymore This closes #307
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. This is backport of commit d141957 from master to maven-3.9.x branch.
This is backport of commit 9ac2d08 from master to maven-3.9.x branch.
(cherry picked from commit 702f52d)
…ation (cherry picked from commit 3dd0afd)
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.
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
…nnot be readded This closes #742
# Conflicts: # maven-core/src/main/java/org/apache/maven/lifecycle/internal/MojoExecutor.java
… mojos executions
(cherry picked from commit 54f9d91)
This closes #754
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
19 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Requires apache/maven-resolver#188
The idea is similar as with resolver transport: add simple(er) switches to maven to control resolver locking aspect. Just as with transport (setting priority), setting proper locking may be cumbersome, as it requires lock factory but also name mapper settings, and there are even pairings that are must (like for file). Instead of relying directly on https://maven.apache.org/resolver/configuration.html here, again as in case of transport, offer a "higher" level settings from Maven itself:
That provides OOTB "experience" to end users (naturally in case of latter two needed configuration and remote services are assumed but not checked for!).
Hence,
mvn -Dmaven.resolver.locking=file ...would make Maven use file locking.