Repository navigation
chore(kokoro): fix java8-osx lock acquisition failure - #14812
Conversation
Fix 'Could not acquire lock(s)' on Mac OS java8-osx builds during Maven install by passing -Daether.syncContext.named.factory=nolock to -T 1C parallel invocations.
|
/gemini review |
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request appends the -Daether.syncContext.named.factory=nolock flag to multiple Maven commands across several Kokoro shell scripts. The reviewer noted that disabling locking during multi-threaded builds (-T 1C) introduces concurrency risks, such as local repository corruption. To improve maintainability and reduce duplication, the reviewer recommended centralizing this configuration by exporting it via MAVEN_OPTS in a common setup script instead of modifying each individual Maven invocation.
There was a problem hiding this comment.
Code Review
This pull request adds the -Daether.syncContext.named.factory=nolock flag to multiple Maven commands across several Kokoro shell scripts (build.sh, common.sh, dashboard.sh, and dependencies.sh) to prevent locking issues during parallel builds. The reviewer suggests defining this option globally using the MAVEN_OPTS environment variable in a shared script like common.sh to avoid code duplication and keep individual Maven commands clean.
|
/gemini review |
There was a problem hiding this comment.
Code Review
This pull request updates the .kokoro/common.sh script to append -Daether.syncContext.named.factory=nolock to the MAVEN_OPTS environment variable. The feedback recommends using ${MAVEN_OPTS:-} to avoid potential unbound variable errors in environments where set -u is enabled.
|
/gemini review |
There was a problem hiding this comment.
Code Review
This pull request updates the .kokoro/common.sh script to increase the Maven resolver named-lock timeout to 300 seconds by setting the MAVEN_OPTS environment variable. This change aims to prevent 'Could not acquire lock(s)' failures during parallel builds. There are no review comments, and I have no additional feedback to provide.
Problem
-T 1C) Maven installs on slower macOS runners can wait longer than the resolver named-lock timeout (30s by default before Maven 3.9.12) and fail withCould not acquire lock(s).Solution
-Daether.syncContext.named.time=900in.mvn/maven.config, matching the Maven 3.9.12+ default, so every Maven invocation in the repo gets the longer lock wait regardless of the Maven version installed on the runner or how scripts setMAVEN_OPTS. Resolver locking stays enabled.