arturobernalg commented on issue #9049: URL: https://github.com/apache/maven/issues/9049#issuecomment-6263909581
I reproduced the before/after with a small standalone program, not just by reading the diff. Using `NamedLockFactoryAdapter` directly with a thread holding an exclusive lock and another trying to acquire the same one: - With maven-resolver 1.9.22 (what Maven 3.9.9 depends on): default timeout 30s, and the exception message is exactly `Could not acquire lock(s)`, with no indication of which artifact is blocked. - - With maven-resolver 2.0.24: default timeout 900s, and the message is `Could not acquire exclusive lock for artifacts: <gav> in 2 SECONDS; consider using 'aether.syncContext.named.time' property to increase lock timeout to a value that fits your environment`. This is `cstamas`'s own fix, linked above (maven-resolver#1644 on master/2.0.x, backported to the 1.9.x line in maven-resolver#1662, released as 1.9.25). I checked the released Maven poms: Maven 3.9.16 already depends on resolver 1.9.27, and Maven 3.10.0 already depends on 2.0.24, so both the longer timeout and the artifact-naming message are in the current releases, no Maven-side change needed. The root cause of occasional timeouts under slow I/O (the "hot artifacts" theory) is unrelated and still open, but the two concrete asks in this thread, a longer default and a message that names the blocked artifact, already shipped. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
