[ 
https://issues.apache.org/jira/browse/MRESOLVER-270?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17585596#comment-17585596
 ] 

Henning Schmiedehausen commented on MRESOLVER-270:
--------------------------------------------------

The problem is that when the metadata is downloaded and stored in the local XML 
file, it does not filter out snapshot versions for a repo where snapshots 
disabled and does not filter out release versions for a repo where releases are 
disabled. So my local "maven-metadata-snapshots.xml" for the "snapshot only 
repo" for e.g. com.google.code.findbugs.jsr305 looks like this:

{{<metadata>}}
{{  <groupId>com.google.code.findbugs</groupId>}}
{{  <artifactId>jsr305</artifactId>}}
{{  <versioning>}}
{{    <latest>3.0.2</latest>}}
{{    <release>3.0.2</release>}}
{{    <versions>}}
{{      <version>2.0.2</version>}}
{{      <version>2.0.3</version>}}
{{      <version>3.0.0</version>}}
{{      <version>3.0.1</version>}}
{{      <version>3.0.2</version>}}
{{    </versions>}}
{{    <lastUpdated>20170331045618</lastUpdated>}}
{{  </versioning>}}
{{</metadata>}}

So the remote repo, which is configured to be snapshot only, no releases serves 
its local metadata file, because I use the same repo in a different context as 
"releases only, no snapshots". In fact, I have a local 
"maven-metadata-releases.xml" file, which is identical (because it was served 
from the same remote repository URL). 

The version range resolver simply loads these files from disk (because it 
trusts them) and then tries to resolve. So a local release artifact 
(com.google.code.findbugs:jsr305:3.0.1) gets mapped by the range resolver to 
the "snapshot" repository because that happened to be configured first. {*}And 
that is wrong{*}. Because the locally stored metadata for that repository says 
"hey, use this". 

should these files be different or have different content? e.g. should the 
"maven-metadata-snapshots.xml" not contain any versions? *probably.*

 

 

 

 

> 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)

Reply via email to