Add an unconditional ns version range filter to filter out all snapshots

[cstamas]

Adding unconditional ns.

Depends on apache/maven-resolver#1516
Related to #2558

[ctubbsii]

Filtering snapshot results does not address #2558, because snapshot repositories are still queried for maven-metadata.xml before the filtering is done. In order to address #2558, the snapshot-only repos need to be filtered out before the metadata is retrieved, with "guilty knowledge" that the snapshot results are going to be filtered out later.

[cstamas]

Yes, that is done by RRF. This feature is complementing it, making sure there is no this or that in the set from which version is being selected.

[cstamas]

There are multiple means to address your issues:

• RRF to not "generate server side 404s"
• ns filter to make sure there is no snapshot selected when range is met, etc

All the existing builds out there, having for example [1.0,2.0], as history shows, half of them want and the other half does not want snapshots in there. So we cannot make it all "this or that way". Maven 3 had them, in Maven 4 you can turn them on off. And for not letting Maven "wandering" on unwanted reposes, use RRF. The two combined fully covers the intent, if I get it right.

[gnodet]

There are multiple means to address your issues:

• RRF to not "generate server side 404s"

rrf only knows about groupId/artifactId i thought, how can it be used to filter out snapshot version resolution and avoid 404s ? that will only work if the repo does not have those artifacts at all, right ?

• ns filter to make sure there is no snapshot selected when range is met, etc

All the existing builds out there, having for example [1.0,2.0], as history shows, half of them want and the other half does not want snapshots in there. So we cannot make it all "this or that way". Maven 3 had them, in Maven 4 you can turn them on off. And for not letting Maven "wandering" on unwanted reposes, use RRF. The two combined fully covers the intent, if I get it right.

Related question about the s filter. I can see it is conditioned by a property ContextualSnapshotVersionFilter.CONFIG_PROP_ENABLE, but I don't see any code in Maven or Resolver that set this property...

[cstamas]

rrf only knows about groupId/artifactId i thought, how can it be used to filter out snapshot version resolution and avoid 404s ? that will only work if the repo does not have those artifacts at all, right ?

Yes, and hence it would work in case Accumulo had: asking for bouncycastle md from RAO. But also yes, in general RRF makes decision on config, and is not directly about "do not ask metadata from RAO".

Related question about the s filter. I can see it is conditioned by a property ContextualSnapshotVersionFilter.CONFIG_PROP_ENABLE, but I don't see any code in Maven or Resolver that set this property...

The s filter have "two modes": when set alone, it is "contextual". When that property is set, becomes "unconditional" (equivalent of ns). I'd perso just remove that property, and differentiate with s and ns (as filters) and not as s AND having some property XXX set...

[cstamas]

Also see #2574

[ctubbsii]

rrf only knows about groupId/artifactId i thought, how can it be used to filter out snapshot version resolution and avoid 404s ? that will only work if the repo does not have those artifacts at all, right ?

Yes, and hence it would work in case Accumulo had: asking for bouncycastle md from RAO. But also yes, in general RRF makes decision on config, and is not directly about "do not ask metadata from RAO".

RRF doesn't fully address the problem. It addresses the 404s, but wouldn't address the unnecessarily high traffic to RAO to collect the RRF information. In our case, we don't want to even touch RAO at all, when RAO is configured for snapshots only, and we are only resolving version ranges. That's because RAO's abuse thresholds are very low (just as it is for other apache.org services), and we find ourselves frequently struggling to stay under the limits. This is because Apache's abuse policies are source IP-based, so whenever you have many users coming from a single source IP address, they appear as a single abusive user, rather than multiple non-abusive users, and get blocked. In this case, there's just no reason for Maven to contact RAO... not even for RRF information. It's better to avoid RAO, rather than many users/builds each reaching out to RAO for RRF information, because that could still trigger abusive thresholds and get people blocked.