[ https://issues.apache.org/jira/browse/MNG-7529?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17598094#comment-17598094 ]
ASF GitHub Bot commented on MNG-7529: ------------------------------------- hgschmie commented on code in PR #795: URL: https://github.com/apache/maven/pull/795#discussion_r958978758 ########## maven-resolver-provider/src/main/java/org/apache/maven/repository/internal/DefaultVersionRangeResolver.java: ########## @@ -242,6 +231,28 @@ private Versioning readVersions( RepositorySystemSession session, RequestTrace t return ( versioning != null ) ? versioning : new Versioning(); } + private Versioning filterVersionsByRepositoryType( Versioning versioning, RemoteRepository remoteRepository ) + { + if ( remoteRepository == null ) + { + return versioning; + } + + Versioning filteredVersions = versioning.clone(); + + for ( String version : versioning.getVersions() ) + { + boolean snapshotVersion = version != null && version.endsWith( SNAPSHOT ); Review Comment: > We are mixing GA and GAV level metadata here, but this is irrelevant (don't want to derail topic). What bothers me more is that we are **again** assuming that "remote metadata is correct" (same situation as with original code, why this bug was revealed in first place: code assumed snapshot repository will return snapshot versions, that metadata is "correct").... so I consider this reasoning fluke. Either we trust remote metadata or not. You are now fixing something by making Maven "reconsider" remote metadata, but on the other hand now you argue "what you have" in your remote metadata 😄 > > Having said this, am again leaning toward that this bug ([MNG-7529](https://issues.apache.org/jira/browse/MNG-7529)) is more about is "bad configuration", basically your snapshot repository is broken (or in other words, your configuration is broken). For snapshot repository (the original report), all you should do in MRM to create **another group** that contains snapshot members only, and you'd be done (as MRM merges maven metadata, making them "mixed"). The version range resolver *explicitly* asks for metadata for releases *and* snapshots: https://github.com/apache/maven/blob/master/maven-resolver-provider/src/main/java/org/apache/maven/repository/internal/DefaultVersionRangeResolver.java#L150-L151 The repository now answers with all versions that it knows for releases and snapshots. But only the client knows what types of artifacts it has enabled for a specific repository (this is *client* side information). So the client, after it asked the repo for "give me any metadata that you know of" needs to filter the result based on what it has enabled a repository for. You may consider that reasoning fluke, but the code does exactly what you asked it to do. You are not *reconsidering* the metadata, but applying filters that only exist locally because they are configured in maven-settings *after* you asked the repo to "give me everything you have". > Maven resolver makes bad repository choices when resolving version ranges > ------------------------------------------------------------------------- > > Key: MNG-7529 > URL: https://issues.apache.org/jira/browse/MNG-7529 > Project: Maven > Issue Type: Bug > Components: Artifacts and Repositories > Affects Versions: 3.8.6 > Reporter: Henning Schmiedehausen > Priority: Major > Fix For: 3.8.x-candidate, 3.9.0, 4.0.0-alpha-1, 4.0.0 > > > This is the same problem as MRESOLVER-270. The problem is actually in the > maven core, not in the resolver. See the description there. >  > This bug is a placeholder for the fix PR. -- This message was sent by Atlassian Jira (v8.20.10#820010)