hgschmie commented on code in PR #795:
URL: https://github.com/apache/maven/pull/795#discussion_r958983789
##########
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:
> If any maven plugin would consider `foo-1.0-20220829.222835-1` a snapshot
version, this is a bug. There is no limitation on how a version is structured
besides "if it ends with `-SNAPSHOT`, it is a snapshot version". The maven
metadata from a remote repository allows mapping of `-SNAPSHOT` to a special,
timestamp structured version which is delivered in the `<snapshotVersions>`
data set so that the resolver can choose a remote file to download. But
nevertheless, the actual artifact version _is_ `-SNAPSHOT`, because that is
what is in the `<versions>` list in the metadata. So checking the remote
snapshot version against a release version is a surefire recipe to introduce
another bug.
Having validated that this assumption is indeed baked into maven-core, I
still consider this a bug. I also feel that this should be a much wider
discussion, so I brought it to the dev-list.
I will make the change to use the ArtifactUtils method, because that IMHO
will allow us to fix that bug in fewer places. Introducing another private
method will actually make it harder to fix.
I still believe that the timestamp check is wrong and should not be done.
But given that it is all over the place (including the dependency resolver), we
should have a discussion first on how to deal with across the whole maven
ecosystem.
--
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: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
