[EXPERIMENT] Resolver locking mode

[cstamas]

Requires apache/maven-resolver#188

The idea is similar as with resolver transport: add simple(er) switches to maven to control resolver locking aspect. Just as with transport (setting priority), setting proper locking may be cumbersome, as it requires lock factory but also name mapper settings, and there are even pairings that are must (like for file). Instead of relying directly on https://maven.apache.org/resolver/configuration.html here, again as in case of transport, offer a "higher" level settings from Maven itself:

• file
• local
• hazelcast
• redisson
• auto (as before this change, let resolver "auto decide") -- similar like for transport

That provides OOTB "experience" to end users (naturally in case of latter two needed configuration and remote services are assumed but not checked for!).

Hence, mvn -Dmaven.resolver.locking=file ... would make Maven use file locking.

[gnodet]

@cstamas what's the difference between default and auto ?
Is auto a placeholder to add some automatic detection of the filesystem if possible and switch between file and ipc (both could be setup without any additional external requirements) ?

[cstamas]

@cstamas what's the difference between default and auto ? Is auto a placeholder to add some automatic detection of the filesystem if possible and switch between file and ipc (both could be setup without any additional external requirements) ?

Just like in #710 the "default" means user provided no input (but Maven does need to configure to achieve it), while "auto" means we let resolver and it's own mechanism (as opposed to session factory in maven) to figure out.

So presence of "auto" is IMHO a must (in case of both, transport and locking) as if someone throws in some resolver extension, that may override/use priority on components, to retain "standard" resolver behavior, or they relied on resolver behavior for historical reasons, simply to not have maven interfere with it.