[
https://issues.apache.org/jira/browse/MNG-7868?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17864395#comment-17864395
]
Daniel Johnson edited comment on MNG-7868 at 7/9/24 9:32 PM:
-------------------------------------------------------------
[~cstamas] - Nothing too exciting, our company leveraged an open-source UML
modeling tool (Eclipse Tigerstripe) for past ~15 years. We wrote a custom
maven plugin to support "generating" those Tigerstripe models into Java runtime
code. It builds on top of the tycho-compiler-plugin (1.7.0) with:
{code:java}
import copied.org.apache.maven.plugin.AbstractCompilerMojo; // from
tycho-compiler-plugin:1.7.0
@Mojo(name = "compile", requiresDependencyResolution = ResolutionScope.COMPILE,
threadSafe = true)
public class TigerstripeCompiler extends AbstractCompilerMojo { ... }
{code}
In that code we setup a few custom compile classpath entries, but I guess the
only relevant section to this problem would be when we add the projects compile
dependencies to the classpath:
{code:java}
for (Artifact artifact : project.getCompileArtifacts()) {
classpath.add(artifact.getFile().getAbsolutePath());
} {code}
If I understand your above comment, this type of access to the compile
artifacts should not cause any issue with the locks? The locks would only be
held during resolution since the Mojo is marked with
'{_}requiresDependencyResolution = ResolutionScope.COMPILE'.{_}
If you have any reason to think the bug may be exacerbated from this custom
plugin in my case specifically, and more likely in the underlying
tycho-compiler-plugin:1.7.0, then I can definitely do more investigation and
potentially try updating to a newer version of Tycho to see if it resolves.
But other failures reported on this bug will be wholly unrelated as this custom
plugin is not used outside my company.
I will also need to pay more attention, I can't say for sure that every failure
I have seen with this lock issue has this plugin in use. Will try to monitor
and update if I can confirm one way or another.
was (Author: hankolerd):
[~cstamas] - Nothing too exciting, our company leveraged an open-source UML
modeling tool (Eclipse Tigerstripe) for past ~15 years. We wrote a custom
maven plugin to support "generating" those Tigerstripe models into Java runtime
code. It builds on top of the tycho-compiler-plugin (1.7.0) with:
{code:java}
import copied.org.apache.maven.plugin.AbstractCompilerMojo; // from
tycho-compiler-plugin:1.7.0
@Mojo(name = "compile", requiresDependencyResolution = ResolutionScope.COMPILE,
threadSafe = true)
public class TigerstripeCompiler extends AbstractCompilerMojo { ... }
{code}
In that code we setup a few custom compile classpath entries, but I guess the
only relevant section to this problem would be when we add the projects compile
dependencies to the classpath:
{code:java}
for (Artifact artifact : project.getCompileArtifacts()) {
classpath.add(artifact.getFile().getAbsolutePath());
} {code}
If I understand your above comment, this type of access to the compile
artifacts should not cause any issue with the locks? The locks would only be
held during resolution since the Mojo is marked with
'{_}requiresDependencyResolution = ResolutionScope.COMPILE'.{_}
If you have any reason to think the bug may be stemming from this custom
plugin, and more likely in the underlying tycho-compiler-plugin:1.7.0 itself,
then I can definitely do more investigation and potentially try updating to a
newer version of Tycho to see if it resolves.
I will also need to pay more attention, I can't say for sure that every failure
I have seen with this lock issue has this plugin in use. Will try to monitor
and update if I can confirm one way or another.
> "Could not acquire lock(s)" error in concurrent maven builds
> ------------------------------------------------------------
>
> Key: MNG-7868
> URL: https://issues.apache.org/jira/browse/MNG-7868
> Project: Maven
> Issue Type: Bug
> Environment: windows, maven 3.9.4
> Reporter: Jörg Hohwiller
> Priority: Major
> Attachments: image-2024-04-10-15-44-37-013.png, screenshot-1.png
>
>
> {code}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-install-plugin:3.1.1:install (default-install)
> on project foo.bar: Execution default-install of goal
> org.apache.maven.plugins:maven-install-plugin:3.1.1:install failed: Could not
> acquire lock(s) -> [Help 1]
> {code}
> I am using maven 3.9.4 on windows:
> {code}
> $ mvn -v
> Apache Maven 3.9.4 (dfbb324ad4a7c8fb0bf182e6d91b0ae20e3d2dd9)
> Maven home: D:\projects\test\software\mvn
> Java version: 17.0.5, vendor: Eclipse Adoptium, runtime:
> D:\projects\test\software\java
> Default locale: en_US, platform encoding: UTF-8
> OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
> {code}
> I searched for this bug and found issues like MRESOLVER-332 that first look
> identical or similar but do not really seem to be related so I decided to
> create this issue.
> For this bug I made the following observations:
> * it only happens with concurrent builds: {{mvn -T ...}}
> * is seems to be windows related (at least mainly happens on windows)
> * it is in-deterministic and is not so easy to create an isolated and simple
> project and a reproducible scenario that always results in this error.
> However, I get this very often in my current project with many modules (500+).
> * it is not specific to the maven-install-plugin and also happens from other
> spots in maven:
> I also got this stacktrace:
> {code}
> Suppressed: java.lang.IllegalStateException: Attempt 1: Could not acquire
> write lock for
> 'C:\Users\hohwille\.m2\repository\.locks\artifact~com.caucho~com.springsource.com.caucho~3.2.1.lock'
> in 30 SECONDS
> at
> org.eclipse.aether.internal.impl.synccontext.named.NamedLockFactoryAdapter$AdaptedLockSyncContext.acquire
> (NamedLockFactoryAdapter.java:202)
> at org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolve
> (DefaultArtifactResolver.java:271)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifacts
> (DefaultArtifactResolver.java:259)
> at
> org.eclipse.aether.internal.impl.DefaultRepositorySystem.resolveDependencies
> (DefaultRepositorySystem.java:352)
> {code}
> See also this related discussion:
> https://github.com/apache/maven-mvnd/issues/836#issuecomment-1702488377
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
