Local repository accessed by multiple Maven instances - how is it solved ?

[Francois Marot]

Hello all,

I would like clarifications on MNG-2802[*] that seems to be solved. If I
understand correctly it solves the problem where multiple simultaneous
Maven executions shared the same local repository.
I have been keeping for years a bit of code in my Jenkinsfiles ensuring the
local repos were accessed only by a single jenkins executor at the same
time, so it seems like I can get rid of this doesn't it ?
I'd like your input on this because reproducing the bug is difficult so I'd
like to be sure before simplifying my Jenkinsfile.

Moreover, does anyone know how this problem is solved technically ? Using
files lock ? Can anybody explain ?

Thanks you and thanks the Maven team for keeping up the good work at such
pace !

François MAROT


* https://issues.apache.org/jira/browse/MNG-2802

Re: Local repository accessed by multiple Maven instances - how is it solved ?

[Thomas Broyer]

>From JIRA links, this is apparently fixed by
https://issues.apache.org/jira/browse/MRESOLVER-131, which means you need
to deploy a Redis server.
There apparently also is an Hazelcast-based version:
https://maven.apache.org/resolver/maven-resolver-named-locks/index.html

On Mon, Oct 4, 2021 at 2:32 PM Francois Marot 
wrote:

> Hello all,
>
> I would like clarifications on MNG-2802[*] that seems to be solved. If I
> understand correctly it solves the problem where multiple simultaneous
> Maven executions shared the same local repository.
> I have been keeping for years a bit of code in my Jenkinsfiles ensuring the
> local repos were accessed only by a single jenkins executor at the same
> time, so it seems like I can get rid of this doesn't it ?
> I'd like your input on this because reproducing the bug is difficult so I'd
> like to be sure before simplifying my Jenkinsfile.
>
> Moreover, does anyone know how this problem is solved technically ? Using
> files lock ? Can anybody explain ?
>
> Thanks you and thanks the Maven team for keeping up the good work at such
> pace !
>
> François MAROT
>
>
> * https://issues.apache.org/jira/browse/MNG-2802
>


-- 
Thomas Broyer
/tɔ.ma.bʁwa.je/ 

Re: Global pre-installation of Maven extensions w/out ~/.m2/lib/ext

[Austin Witt]

Is it broken in that it doesn't actually solve the problem? Or broken in
that it doesn't actually install correctly in Maven?

Regardless, is there a solution you would recommend for solving the "many
concurrent instances of Maven are running against the same local
repository, and sometimes their file writes conflict" problem?

On Sun, Oct 3, 2021 at 10:59 AM Michael Osipov  wrote:

> Am 2021-09-29 um 21:18 schrieb Austin Witt:
> > I wish to install a Maven extension - Takari's Concurrent Safe Local
> > Repository extension (
> >
> http://takari.io/book/30-team-maven.html#concurrent-safe-local-repository
> )
> > - on a system such that it's picked up by all Maven runs.
> >
>
> Don't! It is broken! Throw it away!
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

[ANN] Apache Maven 3.8.3 released

[Michael Osipov]

The Apache Maven team is pleased to announce the release of the Apache 
Maven 3.8.3


Apache Maven is a software project management and comprehension tool. 
Based on the concept
of a project object model (POM), Maven can manage a project's build, 
reporting and documentation

from a central piece of information.

Maven 3.8.3 is available via https://maven.apache.org/download.cgi

The core release is independent of plugin releases. Further releases of 
plugins will be made

separately.

If you have any questions, please consult:

- the web site: https://maven.apache.org/
- the maven-user mailing list: https://maven.apache.org/mailing-lists.html
- the reference documentation: https://maven.apache.org/ref/3.8.3/


Release Notes - Maven - Version 3.8.3

** Bug
* [MNG-7045] - Drop CDI API from Maven
* [MNG-7214] - Bad transitive dependency parent from CDI API
* [MNG-7215] - [Regression] Maven Site Plugin cannot resolve parent 
site descriptor without locale

* [MNG-7216] - Revert MNG-7170
* [MNG-7218] - [Regression] o.a.m.model.Build.getSourceDirectory() 
incorrectly returns absolute dir on 3.8.2
* [MNG-7219] - [Regression] plexus-cipher missing from transitive 
dependencies

* [MNG-7220] - [REGRESSION] test-classpath incorrectly resolved
* [MNG-7251] - Fix threadLocalArtifactsHolder leaking into cloned 
project

* [MNG-7253] - Relocation message is never shown

** New Feature
* [MNG-7164] - Add constructor MojoExecutionException(Throwable)

** Improvement
* [MNG-7235] - Speed improvements when calculating the sorted 
project graph
* [MNG-7236] - The DefaultPluginVersionResolver should cache 
results for the session


** Task
* [MNG-7252] - Fix warnings issued by dependency:analyze
* [MNG-7254] - Expand Windows native libraries for Jansi due to 
JDK-8195129 (workaround)


** Dependency upgrade
* [MNG-6818] - Upgrade Plexus Utils to 3.3.0
* [MNG-6841] - Upgrade Plexus Interpolation to 1.26
* [MNG-7246] - Upgrade Plexus Cipher and Sec Dispatcher to 2.0
* [MNG-7250] - Upgrade Sisu Inject/Plexus to 0.3.5


For more information read 
https://maven.apache.org/docs/3.8.3/release-notes.html


Enjoy!

- The Maven Team

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Global pre-installation of Maven extensions w/out ~/.m2/lib/ext

[Tamás Cservenák]

There is an ongoing thread on users ML about same issue here:
https://lists.apache.org/thread.html/rd30b06bbe69de2466fd49bc665b96f02dfb8c34431cedff678fe1a08%40%3Cusers.maven.apache.org%3E

HTH
T

On Mon, Oct 4, 2021 at 5:28 PM Austin Witt  wrote:

> Is it broken in that it doesn't actually solve the problem? Or broken in
> that it doesn't actually install correctly in Maven?
>
> Regardless, is there a solution you would recommend for solving the "many
> concurrent instances of Maven are running against the same local
> repository, and sometimes their file writes conflict" problem?
>
> On Sun, Oct 3, 2021 at 10:59 AM Michael Osipov 
> wrote:
>
> > Am 2021-09-29 um 21:18 schrieb Austin Witt:
> > > I wish to install a Maven extension - Takari's Concurrent Safe Local
> > > Repository extension (
> > >
> >
> http://takari.io/book/30-team-maven.html#concurrent-safe-local-repository
> > )
> > > - on a system such that it's picked up by all Maven runs.
> > >
> >
> > Don't! It is broken! Throw it away!
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> > For additional commands, e-mail: users-h...@maven.apache.org
> >
> >
>

Re: Local repository accessed by multiple Maven instances - how is it solved ?

[Francois Marot]

Wooohaa, thanks Thomas.
It's a whole new world being revealed to me: I wasn't aware of the huge
work happening on artifact resolvers.
At the same time, it seems not to be available out of the box (needs a
Redis server) so I'll keep my Jenkinsfile hacks for now and will wait
for proper documentation and how-to.
Thanks for the pointers !


*François Marot*



Le lun. 4 oct. 2021 à 15:10, Thomas Broyer  a écrit :

> From JIRA links, this is apparently fixed by
> https://issues.apache.org/jira/browse/MRESOLVER-131, which means you need
> to deploy a Redis server.
> There apparently also is an Hazelcast-based version:
> https://maven.apache.org/resolver/maven-resolver-named-locks/index.html
>
> On Mon, Oct 4, 2021 at 2:32 PM Francois Marot 
> wrote:
>
> > Hello all,
> >
> > I would like clarifications on MNG-2802[*] that seems to be solved. If I
> > understand correctly it solves the problem where multiple simultaneous
> > Maven executions shared the same local repository.
> > I have been keeping for years a bit of code in my Jenkinsfiles ensuring
> the
> > local repos were accessed only by a single jenkins executor at the same
> > time, so it seems like I can get rid of this doesn't it ?
> > I'd like your input on this because reproducing the bug is difficult so
> I'd
> > like to be sure before simplifying my Jenkinsfile.
> >
> > Moreover, does anyone know how this problem is solved technically ? Using
> > files lock ? Can anybody explain ?
> >
> > Thanks you and thanks the Maven team for keeping up the good work at such
> > pace !
> >
> > François MAROT
> >
> >
> > * https://issues.apache.org/jira/browse/MNG-2802
> >
>
>
> --
> Thomas Broyer
> /tɔ.ma.bʁwa.je/  <
> http://xn--nna.ma.xn--bwa-xxb.je/>
>

Re: Local repository accessed by multiple Maven instances - how is it solved ?

[Oliver Fischer]

Yes, these are good news!

Am 04.10.21 um 15:10 schrieb Thomas Broyer:

 From JIRA links, this is apparently fixed by
https://issues.apache.org/jira/browse/MRESOLVER-131, which means you need
to deploy a Redis server.
There apparently also is an Hazelcast-based version:
https://maven.apache.org/resolver/maven-resolver-named-locks/index.html

On Mon, Oct 4, 2021 at 2:32 PM Francois Marot 
wrote:


Hello all,

I would like clarifications on MNG-2802[*] that seems to be solved. If I
understand correctly it solves the problem where multiple simultaneous
Maven executions shared the same local repository.
I have been keeping for years a bit of code in my Jenkinsfiles ensuring the
local repos were accessed only by a single jenkins executor at the same
time, so it seems like I can get rid of this doesn't it ?
I'd like your input on this because reproducing the bug is difficult so I'd
like to be sure before simplifying my Jenkinsfile.

Moreover, does anyone know how this problem is solved technically ? Using
files lock ? Can anybody explain ?

Thanks you and thanks the Maven team for keeping up the good work at such
pace !

François MAROT


* https://issues.apache.org/jira/browse/MNG-2802





--
N Oliver B. Fischer
A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany
P +49 30 44793251
M +49 178 7903538
E o.b.fisc...@swe-blog.net
S oliver.b.fischer
J oliver.b.fisc...@jabber.org
X http://xing.to/obf


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Global pre-installation of Maven extensions w/out ~/.m2/lib/ext

[Bernd Eckenfels]

An easy fix is to run maven with one local Repo cache per executor thread. 
Jenkins has a option for that. Alternatively run the whole build in a container 
with Repo overlay. (I wish Jenkins had more support to prepopulate those)

Gruss
Bernd

--
http://bernd.eckenfels.net

Von: Austin Witt 
Gesendet: Monday, October 4, 2021 5:27:28 PM
An: Maven Users List 
Betreff: Re: Global pre-installation of Maven extensions w/out ~/.m2/lib/ext

Is it broken in that it doesn't actually solve the problem? Or broken in
that it doesn't actually install correctly in Maven?

Regardless, is there a solution you would recommend for solving the "many
concurrent instances of Maven are running against the same local
repository, and sometimes their file writes conflict" problem?

On Sun, Oct 3, 2021 at 10:59 AM Michael Osipov  wrote:

> Am 2021-09-29 um 21:18 schrieb Austin Witt:
> > I wish to install a Maven extension - Takari's Concurrent Safe Local
> > Repository extension (
> >
> http://takari.io/book/30-team-maven.html#concurrent-safe-local-repository
> )
> > - on a system such that it's picked up by all Maven runs.
> >
>
> Don't! It is broken! Throw it away!
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: Global pre-installation of Maven extensions w/out ~/.m2/lib/ext

[Michael Osipov]

Am 2021-10-04 um 17:27 schrieb Austin Witt:

Is it broken in that it doesn't actually solve the problem? Or broken in
that it doesn't actually install correctly in Maven?


It does not solve the problem. It fails miserably. Don't use it.
See here also: https://github.com/takari/takari-local-repository/issues/15

See my answer to the other, related thread.

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Local repository accessed by multiple Maven instances - how is it solved ?

[Michael Osipov]

Am 2021-10-04 um 22:13 schrieb Francois Marot:

"Salut" Michael,

thanks for the detailled answer.
Regarding my Jenkins 'hack' you can totally forget about it: it just
ensures no more than one Maven execution uses a given repo at once by
locating the local repositories in a folder reflecting the executor (which
are kinda Jenkins "threads").
I plan not to use your work right now mostly because it would involve
setting up a Redis Database and my 'hack' still works (despite using a lot
of disk space and being a bit slow).

If I understand correctly after Tams' message, your work is mostly geared
toward running multiple Maven build in parallel and on multiple hosts, all
sharing one big "local" repository through the network. Am I correct ? In
my case, I have multiple Jenkins workers but never thought about making
them collaborate on a shared "local" repo. I'll have to think about it !


Not quite, we have multiple named locks which will give you the 
granularity you need. Either in-JVM only, or multi-JVM. Then it does not 
matter whether it is on the same host or not. You decide, the Redisson 
approach will work. You need to read the docs how named locks are 
discrimnated with a lock impl. That is all. You will benefit. User I was 
talking about has now a huge speed bump due to the shared local repo, 
for free.


M

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Local repository accessed by multiple Maven instances - how is it solved ?

[Michael Osipov]

Am 2021-10-04 um 14:31 schrieb Francois Marot:

Hello all,

I would like clarifications on MNG-2802[*] that seems to be solved. If I
understand correctly it solves the problem where multiple simultaneous
Maven executions shared the same local repository.
I have been keeping for years a bit of code in my Jenkinsfiles ensuring the
local repos were accessed only by a single jenkins executor at the same
time, so it seems like I can get rid of this doesn't it ?
I'd like your input on this because reproducing the bug is difficult so I'd
like to be sure before simplifying my Jenkinsfile.

Moreover, does anyone know how this problem is solved technically ? Using
files lock ? Can anybody explain ?

Thanks you and thanks the Maven team for keeping up the good work at such
pace !


Salut François,

I don't know what you exactly fiddled in your Jenkinsfile, but there is 
no way make it right just with Jenkinsfile foo when you want access 
*one* local repo with *multiple* processes you *must* use an external 
coordinator process.
Forget also about file locks, they are all advisory, at least on 
POSIX-like filesystems. There is no way, or a very hard way to make them 
right. We tried and removed them.


Now, let me give you bit of history: I have integrated/implemented a 
fully working multi-process Redisson-based synchronization lock factory 
for Maven Resolver 1.6.x which ships with Maven 3.8.x. (It has already 
been battle tested for several months by a user on a busy CI server). 
Tamás took it to the next level in Resolver 1.7.x and generalized it to 
a named lock approach where the Redisson Lock Factory plugs in nicely 
with other lock implementations. Almost nine months of work and it works 
very good now.
Now here is the problem: Maven Resolver 1.7.x comes only with Maven 4.x. 
I have created a branch which reconciles best of breed: Maven 3.8.x and 
Maven Resolver 1.7.x. It just works (also verified by this user). I also 
ran more than a thousand builds with 8 parallel processes and 4 threads.
It will easily handle thousands of locks in parralel with an one digit 
percent overhead.


I don't know for what documentation you are waiting for, but everything 
is there, you can start *now* to leverage it: [2], [3]. With Resolver 
2.0.0 and Maven 4.0.0 it will likely be even easier to integrate.


Hazelcast will also work, but Tamás is the special here.

Again: You *must* use an external process to synchronize access. No excuses.

Michael

[1] https://github.com/apache/maven/tree/maven-3.8.x-resolver-1.7.x
[2] https://maven.apache.org/resolver/maven-resolver-named-locks/index.html
[3] 
https://maven.apache.org/resolver/maven-resolver-named-locks-redisson/index.html




-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Local repository accessed by multiple Maven instances - how is it solved ?

[Bernd Eckenfels]

What’s the problem with adivisory locking, as long as Maven honors the advice 
it is the same as it’s a redis lock? (But much less footprint). In fact on the 
same machine it should even work without locking as Long as you use pidfiles?

Gruss
Bernd


--
http://bernd.eckenfels.net

Von: Michael Osipov 
Gesendet: Monday, October 4, 2021 9:15:23 PM
An: users@maven.apache.org 
Betreff: Re: Local repository accessed by multiple Maven instances - how is it 
solved ?

Am 2021-10-04 um 14:31 schrieb Francois Marot:
> Hello all,
>
> I would like clarifications on MNG-2802[*] that seems to be solved. If I
> understand correctly it solves the problem where multiple simultaneous
> Maven executions shared the same local repository.
> I have been keeping for years a bit of code in my Jenkinsfiles ensuring the
> local repos were accessed only by a single jenkins executor at the same
> time, so it seems like I can get rid of this doesn't it ?
> I'd like your input on this because reproducing the bug is difficult so I'd
> like to be sure before simplifying my Jenkinsfile.
>
> Moreover, does anyone know how this problem is solved technically ? Using
> files lock ? Can anybody explain ?
>
> Thanks you and thanks the Maven team for keeping up the good work at such
> pace !

Salut François,

I don't know what you exactly fiddled in your Jenkinsfile, but there is
no way make it right just with Jenkinsfile foo when you want access
*one* local repo with *multiple* processes you *must* use an external
coordinator process.
Forget also about file locks, they are all advisory, at least on
POSIX-like filesystems. There is no way, or a very hard way to make them
right. We tried and removed them.

Now, let me give you bit of history: I have integrated/implemented a
fully working multi-process Redisson-based synchronization lock factory
for Maven Resolver 1.6.x which ships with Maven 3.8.x. (It has already
been battle tested for several months by a user on a busy CI server).
Tamás took it to the next level in Resolver 1.7.x and generalized it to
a named lock approach where the Redisson Lock Factory plugs in nicely
with other lock implementations. Almost nine months of work and it works
very good now.
Now here is the problem: Maven Resolver 1.7.x comes only with Maven 4.x.
I have created a branch which reconciles best of breed: Maven 3.8.x and
Maven Resolver 1.7.x. It just works (also verified by this user). I also
ran more than a thousand builds with 8 parallel processes and 4 threads.
It will easily handle thousands of locks in parralel with an one digit
percent overhead.

I don't know for what documentation you are waiting for, but everything
is there, you can start *now* to leverage it: [2], [3]. With Resolver
2.0.0 and Maven 4.0.0 it will likely be even easier to integrate.

Hazelcast will also work, but Tamás is the special here.

Again: You *must* use an external process to synchronize access. No excuses.

Michael

[1] https://github.com/apache/maven/tree/maven-3.8.x-resolver-1.7.x
[2] https://maven.apache.org/resolver/maven-resolver-named-locks/index.html
[3]
https://maven.apache.org/resolver/maven-resolver-named-locks-redisson/index.html



-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Local repository accessed by multiple Maven instances - how is it solved ?

[Tamás Cservenák]

Hi Bernd,

nothing is wrong with advisory file locking, as long as you don't store
local repo on NFS ;)
Will re-add file locking once I get there, as in my opinion it is the most
"lightweight" MP (multi process) solution on a single host.
Redis and Hazelcast are more for "farms", where several hosts with many
processes (and each with many threads) is bashing local repo (that MAY be
on NFS as well).

Thanks
Tamas

On Mon, Oct 4, 2021 at 9:37 PM Bernd Eckenfels 
wrote:

> What’s the problem with adivisory locking, as long as Maven honors the
> advice it is the same as it’s a redis lock? (But much less footprint). In
> fact on the same machine it should even work without locking as Long as you
> use pidfiles?
>
> Gruss
> Bernd
>
>

Re: Local repository accessed by multiple Maven instances - how is it solved ?

[Michael Osipov]

Tamás,

Redis is so easy to install and get going in 5 minutes that I would 
rather see your energy go into areas which need more attention.


M

Am 2021-10-04 um 22:02 schrieb Tamás Cservenák:

Hi Bernd,

nothing is wrong with advisory file locking, as long as you don't store
local repo on NFS ;)
Will re-add file locking once I get there, as in my opinion it is the most
"lightweight" MP (multi process) solution on a single host.
Redis and Hazelcast are more for "farms", where several hosts with many
processes (and each with many threads) is bashing local repo (that MAY be
on NFS as well).

Thanks
Tamas

On Mon, Oct 4, 2021 at 9:37 PM Bernd Eckenfels 
wrote:


What’s the problem with adivisory locking, as long as Maven honors the
advice it is the same as it’s a redis lock? (But much less footprint). In
fact on the same machine it should even work without locking as Long as you
use pidfiles?

Gruss
Bernd








-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Local repository accessed by multiple Maven instances - how is it solved ?

[Bernd Eckenfels]

Even for nfs fcntl locking can work and create/ln/mv are atomic. Do you know if 
there is any file lock based impl available?

Gruss
Bernd
--
http://bernd.eckenfels.net

Von: Tamás Cservenák 
Gesendet: Monday, October 4, 2021 10:02:27 PM
An: Maven Users List 
Betreff: Re: Local repository accessed by multiple Maven instances - how is it 
solved ?

Hi Bernd,

nothing is wrong with advisory file locking, as long as you don't store
local repo on NFS ;)
Will re-add file locking once I get there, as in my opinion it is the most
"lightweight" MP (multi process) solution on a single host.
Redis and Hazelcast are more for "farms", where several hosts with many
processes (and each with many threads) is bashing local repo (that MAY be
on NFS as well).

Thanks
Tamas

On Mon, Oct 4, 2021 at 9:37 PM Bernd Eckenfels 
wrote:

> What’s the problem with adivisory locking, as long as Maven honors the
> advice it is the same as it’s a redis lock? (But much less footprint). In
> fact on the same machine it should even work without locking as Long as you
> use pidfiles?
>
> Gruss
> Bernd
>
>

Re: Local repository accessed by multiple Maven instances - how is it solved ?

[Francois Marot]

"Salut" Michael,

thanks for the detailled answer.
Regarding my Jenkins 'hack' you can totally forget about it: it just
ensures no more than one Maven execution uses a given repo at once by
locating the local repositories in a folder reflecting the executor (which
are kinda Jenkins "threads").
I plan not to use your work right now mostly because it would involve
setting up a Redis Database and my 'hack' still works (despite using a lot
of disk space and being a bit slow).

If I understand correctly after Tams' message, your work is mostly geared
toward running multiple Maven build in parallel and on multiple hosts, all
sharing one big "local" repository through the network. Am I correct ? In
my case, I have multiple Jenkins workers but never thought about making
them collaborate on a shared "local" repo. I'll have to think about it !

Thanks !

François



Le lun. 4 oct. 2021 à 21:22, Michael Osipov  a écrit :

> Am 2021-10-04 um 14:31 schrieb Francois Marot:
> > Hello all,
> >
> > I would like clarifications on MNG-2802[*] that seems to be solved. If I
> > understand correctly it solves the problem where multiple simultaneous
> > Maven executions shared the same local repository.
> > I have been keeping for years a bit of code in my Jenkinsfiles ensuring
> the
> > local repos were accessed only by a single jenkins executor at the same
> > time, so it seems like I can get rid of this doesn't it ?
> > I'd like your input on this because reproducing the bug is difficult so
> I'd
> > like to be sure before simplifying my Jenkinsfile.
> >
> > Moreover, does anyone know how this problem is solved technically ? Using
> > files lock ? Can anybody explain ?
> >
> > Thanks you and thanks the Maven team for keeping up the good work at such
> > pace !
>
> Salut François,
>
> I don't know what you exactly fiddled in your Jenkinsfile, but there is
> no way make it right just with Jenkinsfile foo when you want access
> *one* local repo with *multiple* processes you *must* use an external
> coordinator process.
> Forget also about file locks, they are all advisory, at least on
> POSIX-like filesystems. There is no way, or a very hard way to make them
> right. We tried and removed them.
>
> Now, let me give you bit of history: I have integrated/implemented a
> fully working multi-process Redisson-based synchronization lock factory
> for Maven Resolver 1.6.x which ships with Maven 3.8.x. (It has already
> been battle tested for several months by a user on a busy CI server).
> Tamás took it to the next level in Resolver 1.7.x and generalized it to
> a named lock approach where the Redisson Lock Factory plugs in nicely
> with other lock implementations. Almost nine months of work and it works
> very good now.
> Now here is the problem: Maven Resolver 1.7.x comes only with Maven 4.x.
> I have created a branch which reconciles best of breed: Maven 3.8.x and
> Maven Resolver 1.7.x. It just works (also verified by this user). I also
> ran more than a thousand builds with 8 parallel processes and 4 threads.
> It will easily handle thousands of locks in parralel with an one digit
> percent overhead.
>
> I don't know for what documentation you are waiting for, but everything
> is there, you can start *now* to leverage it: [2], [3]. With Resolver
> 2.0.0 and Maven 4.0.0 it will likely be even easier to integrate.
>
> Hazelcast will also work, but Tamás is the special here.
>
> Again: You *must* use an external process to synchronize access. No
> excuses.
>
> Michael
>
> [1] https://github.com/apache/maven/tree/maven-3.8.x-resolver-1.7.x
> [2]
> https://maven.apache.org/resolver/maven-resolver-named-locks/index.html
> [3]
>
> https://maven.apache.org/resolver/maven-resolver-named-locks-redisson/index.html
>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>