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