Update mvnd to include Maven Resolver 1.7

[cstamas]

As mvnd itself is Java8 lang level, it is completely
okay to up resolver to 1.7 (that is java8 as well)
and get it's improvements.

The only reason why Maven 3.8.x CANNOT use resolver
1.7 is that it is still Java7 level.

[michael-o]

Makes sense!

[cstamas]

Unsure about macOS failure (am on Linux), is it me or something else?

[gnodet]

Unsure about macOS failure (am on Linux), is it me or something else?

The whole build did pass for me, let me start CI again.

[cstamas]

So, with 1.7.x you get "local" (semaphore or reentrantrw) sync context out of box, but also 1.7.3 may have this one as well: apache/maven-resolver#131

[gnodet]

So, with 1.7.x you get "local" (semaphore or reentrantrw) sync context out of box, but also 1.7.3 may have this one as well: apache/maven-resolver#131

So +1 for the local one, though it has been already added to mvnd.
I still don't really understand the benefits of the NamedLock : this interface seems a regression to me compared to the SyncContext ... As for the implementation, my understanding is that they require an external process to be setup, which I don't think is worth it in simple cases, which means it's a good thing when your local repository is shared across several servers (is that ever the case ?). For simple scenario, I'd much rather use the mvnd IPC implementation at https://github.com/mvndaemon/mvnd/tree/master/sync/src/main/java/org/mvndaemon/mvnd/sync which requires zero setup and should be faster (using unix sockets and a native server when possible).

[cstamas]

No, that's misunderstanding. There are several NamedLock providers and only SOME of them needs extra infra (external process):

• rwlock-local (default), uses JVM ReentrantReadWriteLock per lock name, usable for MT builds.
• semaphore-local, uses JVM Semaphore per lock name, usable for MT builds.
• noop, implement no-op locking (no locking). For experimenting only. Has same functionality as old "nolock"
  SyncContextFactory implementation.

and the pointed PR adds file-lock provider using NIO FileLock usable for MP. None of these above needs anything external (infra/process).

There are TWO MP providers, for Redis and Hazelcast, and those two DO need external Redis or Hazelcast.

[cstamas]

Also, NamedLock does not get in your way, you don't have to use them (as mvnd does: it replaces SyncContextFactory), they are merely an "internal detail", how resolver locks are implemented and used via resolver "adapter" SyncContextFactory.

[gnodet]

No, that's misunderstanding. There are several NamedLock providers and only SOME of them needs extra infra (external process):

• rwlock-local (default), uses JVM ReentrantReadWriteLock per lock name, usable for MT builds.
• semaphore-local, uses JVM Semaphore per lock name, usable for MT builds.
• noop, implement no-op locking (no locking). For experimenting only. Has same functionality as old "nolock"
  SyncContextFactory implementation.

and the pointed PR adds file-lock provider using NIO FileLock usable for MP. None of these above needs anything external (infra/process).

There are TWO MP providers, for Redis and Hazelcast, and those two DO need external Redis or Hazelcast.

Yes, what I meant is that in the context of mvnd, those two are the only ones that can provide locking between the daemons. The file lock seems really promising though.

[ppalaga]

@gnodet is this good to merge?
@cstamas could you please squash your commits and possibly rebase on top of recent main?

[cstamas]

@ppalaga done