Correct, file-lock does work cross-VM, T
On Tue, Jun 21, 2022 at 12:01 PM Konrad Windszus <konra...@gmx.de> wrote: > Hi Mirko, > Right, but isn’t “file-lock” relying internally on > https://docs.oracle.com/javase/7/docs/api/java/nio/channels/FileLock.html > which says: "This file-locking API is intended to map directly to the > native locking facility of the underlying operating system. Thus the locks > held on a file should be visible to all programs that have access to the > file, regardless of the language in which those programs are written.” > > Therefore I assume “file-lock” should work also cross VMs or is that > assumption not correct? > > Konrad > > > On 21. Jun 2022, at 11:57, mfriedenha...@gmx.de wrote: > > > > Hi Konrad, > > > > citing the linked web site: "Local named locks are only suited within > one JVM with a multithreaded build. Sharing a local repository between > multiple Maven processes (i.e., on a busy CI server) requires a distributed > named lock!" > > > > Best Regards > > Mirko Friedenhagen > > — > > Sent from my mobile > > > > Am 21.06.22 um 10:20 schrieb Konrad Windszus > > > >> Thanks for that suggestion. I know about that workaround. But to speed > up builds and to reduce disk space usage I would really like to use a > shared repo. > >> > >> I was wondering if there is any experience with the simple "file-lock” > [1]. That has the advantage that it doesn’t need additional libraries > (IIUC). Configuration should be as easy as setting > “aether.syncContext.named.factory” to “file-lock” [2]. Unfortunately even > Maven 3.8.6 still ships with Resolver 1.6.3 [3] and it seems the suggested > branch https://github.com/apache/maven/commits/maven-3.8.x-resolver-1.7.x > is a bit outdated now… > >> > >> Konrad > >> > >> [1] - > https://github.com/apache/maven-resolver/blob/2af7bff2a5238bf2597cd7a46b60a12779ee31a3/maven-resolver-named-locks/src/main/java/org/eclipse/aether/named/providers/FileLockNamedLockFactory.java > >> [2] - https://maven.apache.org/resolver/configuration.html > >> [3] - https://maven.apache.org/components/resolver/maven-3.8.x.html > >> > >> > >>> On 21. Jun 2022, at 10:01, Lasse Lindqvist < > lasse.k.lindqv...@gmail.com> wrote: > >>> > >>> Hi. If you want to have pipeline build safely, you also have an > >>> alternative. With the withMaven clause (Pipeline Maven Integration > Plugin) > >>> you can use something like > >>> > >>> > >>> > >>> *withMaven(maven: 'Maven123', mavenLocalRepo: > >>> '$WORKSPACE/../../.m2/$EXECUTOR_NUMBER/repository') { // Run my Maven > >>> commands here* > >>> * }* > >>> It will use the workspace folder, travel out of it to a parent > location and > >>> make a sibling .m2 folder and unique subfolder there based on the > executor > >>> number. This way the folders used are executor specific and there will > be > >>> no concurrency problems. The downside is that it will use more disk > space > >>> because many artifacts are stored multiple times. > >>> > >>> ti 21. kesäk. 2022 klo 10.51 Konrad Windszus (k...@apache.org) > kirjoitti: > >>> > >>>> Hi, > >>>> By default Jenkins uses a global Maven repository which is accessed in > >>>> parallel by multiple jobs running in dedicated VMs. To prevent race > >>>> conditions one should probably configure one of the distributed named > locks > >>>> outlined in > >>>> > https://maven.apache.org/resolver/maven-resolver-named-locks/index.html < > >>>> > https://maven.apache.org/resolver/maven-resolver-named-locks/index.html>. > >>>> Is there any recommendation which one to pick and also some concrete > hints > >>>> how to set that up with Jenkins (Pipelines, leveraging > >>>> https://www.jenkins.io/doc/pipeline/steps/pipeline-maven/ < > >>>> https://www.jenkins.io/doc/pipeline/steps/pipeline-maven/>) > >>>> > >>>> Is ASF Jenkins using named locks already? > >>>> Thanks for any pointers > >>>> > >>>> Konrad > >>>> > >>>> > >> > >> > >> --------------------------------------------------------------------- > >> 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 > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > >
