[MDEP-726] Resolve artifact item versions from transitive dependencies - #1667
[MDEP-726] Resolve artifact item versions from transitive dependencies#1667wilx wants to merge 4 commits into
Conversation
Allow copy and unpack artifact items to infer omitted versions from scope-specific dependency graphs while preserving direct dependency and dependency-management lookup. Fixes apache#1240.
| <artifactItem> | ||
| <groupId>org.apache.maven.its.dependency</groupId> | ||
| <artifactId>ResourceArtifact-relocation</artifactId> | ||
| <version>1.0</version> |
There was a problem hiding this comment.
we should probably keep the existing test as is and add new ones without the version
There was a problem hiding this comment.
I reverted this and added separate tests.
| ArtifactHandlerManager artifactHandlerManager, | ||
| RepositorySystem repositorySystem, | ||
| ResolverUtil resolverUtil) { | ||
| ResolverUtil resolverUtil, |
There was a problem hiding this comment.
This incompatibly changes a published API
There was a problem hiding this comment.
There is not a single use that is outside of this plugin that I could find in any Maven sources.
But I will try to preserve the signature.
| /** | ||
| * Classpath scope from which to infer a missing version when the artifact is not found in direct dependencies or | ||
| * dependency management. Supported values are {@code compile}, {@code runtime}, and {@code test}. When omitted, | ||
| * all three dependency graphs are considered and must agree on the selected version. |
There was a problem hiding this comment.
Then it is an error and the user has to deal with it by either specifying the dependencyScope or by giving explicit version`.
There was a problem hiding this comment.
will this mean users now get errors on projects where they saw no errors before?
There was a problem hiding this comment.
No. This entire patch is strictly improving the situation. Before the patch, you had to add the version explicitly. With the patch, you can omit the version and it will get resolved but it has to be unambiguous.
| * @since 3.11.1 | ||
| */ | ||
| @Parameter | ||
| private String dependencyScope; |
There was a problem hiding this comment.
scope is different than the other fields. They're about the artifact itself. This is about how the artifact is used. This might be confusing artifacts and dependencies on artifacts. An artifact doesn't really have a scope.
There was a problem hiding this comment.
See above. This is used to guide the dependency version resolution for the artifact if the version is ambiguous due to different version of the artifact in different scopes.
|
I have pushed the formatting fix. |
2 participants
Summary
Allow
dependency:copyanddependency:unpackartifact items to omit their version when the artifact is present only as a transitive project dependency.The existing direct-dependency and dependency-management lookups remain authoritative. If neither supplies a version, the plugin lazily collects the requested compile, runtime, or test dependency graph through Maven Resolver and looks up the selected artifact version. An optional
dependencyScopesetting resolves cases where different classpaths select different versions; without it, conflicting selections are reported rather than guessed.Artifact matching first uses the complete group ID, artifact ID, type, and classifier coordinates and then preserves the existing GA fallback. The resolved graphs are cached per scope in immutable GA-indexed maps. Existing relocation behavior is retained because the original model coordinates are checked before Resolver's post-relocation graph.
This implementation uses the Maven shared dependency graph APIs supported by both Maven 3.x and Maven 4.x.
Fixes #1240.
Verification
mvn verify— 415 tests passed, with one existing skip.mvn -Prun-its verify— all 103 integration projects passed.mdep-726-*,copy-relocation, andunpack-relocationintegration tests passed with:git diff --checkpassed.Following this checklist to help us incorporate your
contribution quickly and easily:
Note that commits might be squashed by a maintainer on merge.
This may not always be possible but is a best-practice.
mvn verifyto make sure basic checks pass.A more thorough check will be performed on your pull request automatically.
mvn -Prun-its verify).If your pull request is about ~20 lines of code you don't need to sign an
Individual Contributor License Agreement if you are unsure
please ask on the developers list.
To make clear that you license your contribution under
the Apache License Version 2.0, January 2004
you have to acknowledge this by using the following check-box.