hgschmie commented on code in PR #795:
URL: https://github.com/apache/maven/pull/795#discussion_r958907258
##########
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:
I think blaming the user for "bad configuration" is not the right thing. If
the maven settings configuration is invalid, then maven should fail right away
and flag this as "not supported / illegal configuration". As it does not, maven
should do the right thing, even though you feel that this is not right (spoiler
alert: I did not come up with that setup, I saw setups like this at various
organizations).
The assumption in the code ("snapshot repositories only delivers snapshots")
is a flawed one, because the repository has no idea that it is considered as a
source of "snapshots only". There is no communication from the client to the
service asking for "versions that are snapshots / non-snapshots only". Same for
"releases only". A repository that has both snapshots and releases (which is a
very common setup for corporate repositories / proxy repos etc.) is perfectly
fine to report these versions in its version list.
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.
I believe that the proposed fix is correct.
--
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]