You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@maven.apache.org by "Tamás Cservenák (Jira)" <ji...@apache.org> on 2022/08/26 18:26:00 UTC
[jira] [Comment Edited] (MRESOLVER-270) Maven resolver makes bad repository choices when resolving version ranges
[ https://issues.apache.org/jira/browse/MRESOLVER-270?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17585581#comment-17585581 ]
Tamás Cservenák edited comment on MRESOLVER-270 at 8/26/22 6:25 PM:
--------------------------------------------------------------------
Questions that are not really clear to me:
* Why does/would two repositories, that in _theory_ cannot have overlapping versions (release vs snapshot) return same versions?
* Why is expected that Maven resolve this unexpected situation (snapshot repository returns release versions?)
* This is clearly problem on server side: as I wrote long time ago, groups are bad, and exactly due this "metadata merge" they do (am really sorry for "inventing" grouped repository with Proximity in 2006, sorry for that, mea culpa).
* try to target "more specific" repositories (members of the group), instead to target groups, find the member release and member snapshot?
but i need to dig more... but also to understand the intent here.
was (Author: cstamas):
Questions that are not really clear to me:
* Why does/would two repositories, that in _theory_ cannot have overlapping versions (release vs snapshot) return same versions?
* Why is expected that Maven resolve this unexpected situation (snapshot repository returns release versions?)
* This is clearly problem on server side: as I wrote long time ago, groups are bad, and exactly due this "metadata merge" they do (am really sorry for "inventing" grouped repository with Proximity in 2006, sorry for that, mea culpa).
* try to target "more specific" repositories (members of the group), instead to target groups, find the member release and member snapshot?
but i need to dig more...
> Maven resolver makes bad repository choices when resolving version ranges
> -------------------------------------------------------------------------
>
> Key: MRESOLVER-270
> URL: https://issues.apache.org/jira/browse/MRESOLVER-270
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
> Affects Versions: 1.6.3
> Reporter: Henning Schmiedehausen
> Priority: Major
>
> This also affects the maven-resolver-provider which is part of Maven core. I still file the bug here because it is easier to explain.
> I have a repository setup like this:
> {quote} <profiles>
> <profile>
> <id>repo</id>
> <repositories>
> <repository>
> <id>snapshots</id>
> <url>[https://.../maven-public/]</url>
> <releases>
> <enabled>false</enabled>
> <updatePolicy>never</updatePolicy>
> <checksumPolicy>warn</checksumPolicy>
> </releases>
> <snapshots>
> <enabled>true</enabled>
> <updatePolicy>interval:180</updatePolicy>
> <checksumPolicy>fail</checksumPolicy>
> </snapshots>
> <layout>default</layout>
> </repository>
> <repository>
> <id>central</id>
> <url>[https://...|https://.../]/maven-public/</url>
> <releases>
> <enabled>true</enabled>
> <updatePolicy>never</updatePolicy>
> <checksumPolicy>warn</checksumPolicy>
> </releases>
> <snapshots>
> <enabled>false</enabled>
> <updatePolicy>interval:180</updatePolicy>
> <checksumPolicy>fail</checksumPolicy>
> </snapshots>
> <layout>default</layout>
> </repository>
> </repositories>
> {quote}
>
> Maven is trying to resolve the metadata from this component: [https://repo1.maven.org/maven2/com/googlecode/owasp-java-html-sanitizer/owasp-java-html-sanitizer/20220608.1/owasp-java-html-sanitizer-20220608.1.pom]
> which contains (after resolution):
>
> {quote}<dependency>
> <groupId>com.google.code.findbugs</groupId>
> <artifactId>jsr305</artifactId>
> <version>[2.0.1,)</version>
> <scope>provided</scope>
> </dependency>
> {quote}
> {quote}<dependency>
> <groupId>com.google.code.findbugs</groupId>
> <artifactId>annotations</artifactId>
> <version>[2.0.1,)</version>
> <scope>provided</scope>
> </dependency>
>
> {quote}
>
> what happens now is that maven uses the DefaultVersionRangeResolver, which contains this line:
> {quote}{{Metadata metadata = new DefaultMetadata( request.getArtifact().getGroupId(), request.getArtifact().getArtifactId(), MAVEN_METADATA_XML, Metadata.Nature.RELEASE_OR_SNAPSHOT );}}
> {quote}
> So it tries to resolve the dependency range against all the repositories.
> By searching for "Nature.RELEASE_OR_SNAPSHOT", both configured repositories (snapshot and central) are eligible and selected. And by the order, the snapshot repository is chosen first.
> Because both remote repositories map to the same local repository, the following version check in lines 210 - 231 iterates over the local versions and finds the matching version in the "snapshots" repository.
> All of this code is called from the ProjectDependenciesResolver (which is injected into a mojo as a component), when calling resolve() on a DependencyResolutionRequest for this specific component (com.googlecode.owasp-java-html-sanitizer:owasp-java-html-sanitizer:bundle:20220608.1). It results in the following (slightly obscure) error message:
> {quote}Could not resolve dependencies for project com.googlecode.owasp-java-html-sanitizer:owasp-java-html-sanitizer:bundle:20220608.1: The following artifacts could not be resolved: com.google.code.findbugs:jsr305:jar:3.0.2, com.google.code.findbugs:annotations:jar:3.0.1u2: Could not find artifact com.google.code.findbugs:jsr305:jar:3.0.2
> {quote}
> However, that artifact is clearly present both in the local and remote repository.
>
> What happens is that the ProjectDependenciesResolver tries to resolve the (release) artifact om.google.code.findbugs:jsr305:jar:3.0.2 against the resolved repository (which is a snapshot only repository) and that repository rightfully refuses to resolve it. Hence the error message.
> I can fix this (which confirms this behavior) by removing the snapshot repository from the maven_settings.xml and enable snapshots for the "central" repository.
>
> Expected resolution: The DefaultVersionRangeResolver will not select the "first repository that contains the version" but looks at snapshot/release enabled and choose based on that information.
> I might find time to whip up a bug fix.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)