RRF: No Catch-All available when you only want to deny some groupIds

[bmarwell]

Affected version

4.0.0-rc-4

Bug description

Use case

For a specific repository, you do not want to make requests for certain artifacts identified by groupId, e.g. invalid.mycompany.

Problem description

When creating a RRF for groupIds which are not to be loaded from a specific repository:

!invalid.mycompany

Then no artifact will be loaded at all from this repository:

[INFO] Loaded 3 group rules for remote repository maven-central
[INFO] [stdout] ?
[INFO] [stdout]   ?invalid
[INFO] [stdout]     -mycompany

[…]

[ERROR] Extension eu.maveniverse.maven.mimir:extension3:0.10.4 or one of its dependencies could not be resolved: Plugin eu.maveniverse.maven.mimir:extension3:0.10.4 or one of its dependencies could not be resolved:
	G:eu.maveniverse.maven.mimir NOT allowed from nexus-central (https://repo.company.invalid/repository/maven-central/, default, releases)

There is no (documented) catch-all either: https://maven.apache.org/resolver/remote-repository-filtering.html

Workaround

As a workaround, just define everything as allowed before that:

aopalliance
ch
eu
de
dev
com
commons-beanutils
commons-cli
commons-codec
commons-collections
commons-chain
commons-digester
commons-io
commons-jxpath
commons-lang
commons-logging
dom4j
guru
jakarta
javax
info
io
log4j
net
nl
org
oro
xerces

!invalid.mycompany

[gnodet]

Should we support wildcards and bail out on the first matched rules?
We could thus write:

!invalid.mycompany
*

The default rule could be left as !*.

@cstamas thouhts ?

[cstamas]

The default use case for group filter was "allow none + allow selectively", as explained in doco and demo. The whole reason for groupId was in fact to fight against forges exposing their "public" supergroup that among forge things offered central artifacts as well. So the original idea was "prefix is negative (what is for sure not here) and group is positive filter (what G you can get)" and the two nicely supplement each other.

But I agree, adding "def rule" is not biggie.

[cstamas]

btw, this is maven-resolver issue rather than Maven.