cstamas commented on code in PR #795:
URL: https://github.com/apache/maven/pull/795#discussion_r958105690
##########
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 :smile:
Having said this, am again leaning toward that this bug (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").
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
