Closed blacelle closed 1 year ago
@blacelle This is a strange one, we run our integration tests on github actions in parallel and those all work. I presume you cannot share what you are running more than you have here. If that is the case, can you see if it is feasible to produce a small sample that has this issue or possibly look in our readme at how we run integration tests and give any pointers into what we are doing that may differ that we might try to cause same issue?
I presume you cannot share what you are running more than you have here.
Indeed, this happens with a private project. I'm not able to reproduce with public projects with similar configuration.
I see in https://github.com/apache/ant/blob/master/src/main/org/apache/tools/ant/Project.java#L1300 that given piece of code may rely on System.in, which may explains something getting stuck.
Given the 3 ExecuteJava seems to be relying on the same underlying BufferedInputStream, I would guess there are conflicting with each others, as I would not expect these 3 modules to interact in such a way. Maybe one module consumed part of the input, and the other module in waiting indefinitely for some input consumed by the other thread.
I suppose this is not reproduced in spotbugs own integration tests due to some race-condition
https://github.com/spotbugs/spotbugs/blob/master/spotbugs/src/main/java/edu/umd/cs/findbugs/TextUICommandLine.java#L409 seems to confirms the 3 modules relies on System.in. Maybe we lack a synchronized block around https://github.com/spotbugs/spotbugs/blob/master/spotbugs/src/main/java/edu/umd/cs/findbugs/TextUICommandLine.java#L297, to easily circumvent such concurrent use of System.in
We have the same issue, with the same stack traces, so one is waiting for the System.in, and the others are waiting for that first one.
Could the auxclasspath passed in the arguments file or in a separate file instead of the System.in?
$ java --version
openjdk 17.0.3 2022-04-19
OpenJDK Runtime Environment JBR-17.0.3+7-463.3-nomod (build 17.0.3+7-b463.3)
OpenJDK 64-Bit Server VM JBR-17.0.3+7-463.3-nomod (build 17.0.3+7-b463.3, mixed mode)
$ mvn --version
Apache Maven 3.8.6 (84538c9988a25aec085021c365c560670ad80f63)
Maven home: /opt/maven
Java version: 17.0.3, vendor: JetBrains s.r.o., runtime: /home/gabor/bin/jbrsdk
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "5.10.102.1-microsoft-standard-wsl2", arch: "amd64", family: "unix"
Blocking thread:
stackTrace:
java.lang.Thread.State: RUNNABLE
at java.io.FileInputStream.readBytes(java.base@17.0.3/Native Method)
at java.io.FileInputStream.read(java.base@17.0.3/FileInputStream.java:276)
at java.io.BufferedInputStream.read1(java.base@17.0.3/BufferedInputStream.java:282)
at java.io.BufferedInputStream.read(java.base@17.0.3/BufferedInputStream.java:343)
- locked <0x00000007000e5b60> (a java.io.BufferedInputStream)
at org.apache.tools.ant.Project.defaultInput(Project.java:1306)
at org.apache.tools.ant.Project.demuxInput(Project.java:1325)
at org.apache.tools.ant.DemuxInputStream.read(DemuxInputStream.java:73)
at sun.nio.cs.StreamDecoder.readBytes(java.base@17.0.3/StreamDecoder.java:270)
at sun.nio.cs.StreamDecoder.implRead(java.base@17.0.3/StreamDecoder.java:313)
at sun.nio.cs.StreamDecoder.read(java.base@17.0.3/StreamDecoder.java:188)
- locked <0x00000007010fb548> (a java.io.InputStreamReader)
at java.io.InputStreamReader.read(java.base@17.0.3/InputStreamReader.java:177)
at java.io.BufferedReader.fill(java.base@17.0.3/BufferedReader.java:162)
at java.io.BufferedReader.readLine(java.base@17.0.3/BufferedReader.java:329)
- locked <0x00000007010fb548> (a java.io.InputStreamReader)
at java.io.BufferedReader.readLine(java.base@17.0.3/BufferedReader.java:396)
at edu.umd.cs.findbugs.TextUICommandLine.handleOption(TextUICommandLine.java:411)
at edu.umd.cs.findbugs.config.CommandLine.parse(CommandLine.java:338)
at edu.umd.cs.findbugs.config.CommandLine.parse(CommandLine.java:300)
at edu.umd.cs.findbugs.FindBugs.processCommandLine(FindBugs.java:345)
at edu.umd.cs.findbugs.FindBugs2.main(FindBugs2.java:1221)
4 blocked threads:
java.lang.Thread.State: BLOCKED (on object monitor)
at java.io.BufferedInputStream.read(java.base@17.0.3/BufferedInputStream.java:334)
- waiting to lock <0x00000007000e5b60> (a java.io.BufferedInputStream)
at org.apache.tools.ant.Project.defaultInput(Project.java:1306)
at org.apache.tools.ant.Project.demuxInput(Project.java:1325)
at org.apache.tools.ant.DemuxInputStream.read(DemuxInputStream.java:73)
at sun.nio.cs.StreamDecoder.readBytes(java.base@17.0.3/StreamDecoder.java:270)
at sun.nio.cs.StreamDecoder.implRead(java.base@17.0.3/StreamDecoder.java:313)
at sun.nio.cs.StreamDecoder.read(java.base@17.0.3/StreamDecoder.java:188)
- locked <0x00000007010282b8> (a java.io.InputStreamReader)
at java.io.InputStreamReader.read(java.base@17.0.3/InputStreamReader.java:177)
at java.io.BufferedReader.fill(java.base@17.0.3/BufferedReader.java:162)
at java.io.BufferedReader.readLine(java.base@17.0.3/BufferedReader.java:329)
- locked <0x00000007010282b8> (a java.io.InputStreamReader)
at java.io.BufferedReader.readLine(java.base@17.0.3/BufferedReader.java:396)
at edu.umd.cs.findbugs.TextUICommandLine.handleOption(TextUICommandLine.java:411)
at edu.umd.cs.findbugs.config.CommandLine.parse(CommandLine.java:338)
at edu.umd.cs.findbugs.config.CommandLine.parse(CommandLine.java:300)
at edu.umd.cs.findbugs.FindBugs.processCommandLine(FindBugs.java:345)
at edu.umd.cs.findbugs.FindBugs2.main(FindBugs2.java:1221)
Could we fix the indication spotbugs maven plugin is thread-safe for now? https://github.com/spotbugs/spotbugs-maven-plugin/blob/spotbugs/src/main/groovy/org/codehaus/mojo/spotbugs/CheckMojo.groovy#L34
Will look more at this. Unclear why read of system in is performed, this isn't interactive. Same with code over in spotbugs. Not following how we get to think we are interactive.
Sent from my Verizon, Samsung Galaxy smartphone Get Outlook for Androidhttps://aka.ms/AAb9ysg
From: Benoit Lacelle @.> Sent: Saturday, January 21, 2023 7:09:05 AM To: spotbugs/spotbugs-maven-plugin @.> Cc: Jeremy Landis @.>; Comment @.> Subject: Re: [spotbugs/spotbugs-maven-plugin] Parallel build without forking in a multi-module leads to spotbugs getting stuck (Issue #488)
Could we fix the indication spotbugs maven plugin is thread-safe for now? https://github.com/spotbugs/spotbugs-maven-plugin/blob/spotbugs/src/main/groovy/org/codehaus/mojo/spotbugs/CheckMojo.groovy#L34https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fspotbugs%2Fspotbugs-maven-plugin%2Fblob%2Fspotbugs%2Fsrc%2Fmain%2Fgroovy%2Forg%2Fcodehaus%2Fmojo%2Fspotbugs%2FCheckMojo.groovy%23L34&data=05%7C01%7C%7Cf35101ecdd6c4df49d1808dafba84b3d%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C638098997479417808%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=FlqTFkDK6G0mrUTaiSYdfbVCAu3DpnDXCx%2FKUVBlBLc%3D&reserved=0
— Reply to this email directly, view it on GitHubhttps://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fspotbugs%2Fspotbugs-maven-plugin%2Fissues%2F488%23issuecomment-1399239452&data=05%7C01%7C%7Cf35101ecdd6c4df49d1808dafba84b3d%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C638098997479417808%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=x0jst3si%2BV%2BwrxzGcXyAnM8E6F285d7eYGXRL1Nk0KQ%3D&reserved=0, or unsubscribehttps://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAAHODIZ45VAHEMFLRU2ZJBDWTPGWDANCNFSM6AAAAAAQMNEKU4&data=05%7C01%7C%7Cf35101ecdd6c4df49d1808dafba84b3d%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C638098997479417808%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=Fz5ibEBqtwFRLpFFpv7orZWxgj32Ht2G2ALuV5DIugE%3D&reserved=0. You are receiving this because you commented.Message ID: @.***>
I open a PR ins spotbugs to synchronize the System.in reads. We would need to synchronize the write also (else multiple writes would interleave in System.in). Alternativaly, we could add some shorter timeout in the read. It would not prevent issues, but it would prevent being stuck for 10 minutes.
Not sure I follow how we are using UI during normal spotbugs run, that logic would indicate asking for input but that run isn't going to do that. feels like the GUI is being used during that type of run, can you confirm that? Having a hard time understanding it otherwise. The change on spotbugs is ok but it really shouldn't call out its due to maven plugin because gradle could do the same.
@blacelle Unlikely I'll add this is not thread safe here as I don't plan to release until next spotbugs at the current moment. Can you show me full setup you are using though as I'm still perplexed at why system.in is used during normal spotbugs execution. That is for the GUI based on naming alone and system in expects to provide some system input. I'm confused how that would be getting executed. I haven't looked very deep though but just confused on how maven plugin run would ever be wanting system input like that. Possibly we are missing some features here, not sure or maybe your run was GUI based to launch that and that causes the issue.
feels like the GUI is being used during that type of run, can you confirm that?
No.
The change on spotbugs is ok but it really shouldn't call out its due to maven plugin because gradle could do the same.
I may dig into spotbugs-gradle if it was necessary.
Here is a typical configuration producing this issue:
https://github.com/solven-eu/cleanthat/blob/master/pom.xml#L517-L547
<plugin>
<!--https://spotbugs.github.io/spotbugs-maven-plugin/index.html -->
<groupId>com.github.spotbugs</groupId>
<artifactId>spotbugs-maven-plugin</artifactId>
<version>${spotbugs.version}</version>
<configuration>
<excludeFilterFile>style/pepper.spotbugs.xml</excludeFilterFile>
</configuration>
<dependencies>
<dependency>
<!-- This dependency holds the default configuration -->
<groupId>io.github.solven-eu.pepper</groupId>
<artifactId>pepper-static</artifactId>
<version>${pepper.version}</version>
<scope>runtime</scope>
</dependency>
</dependencies>
<executions>
<execution>
<id>check</id>
<goals>
<goal>check</goal>
</goals>
<!-- default phase is verify, which is after tests. -->
<!-- We prefer to run static analysis before tests not to wait -->
<phase>${staticChecks}</phase>
</execution>
</executions>
</plugin>
and I get the issue with cmd like 'mvn install -T 8
'
Here is the mvn code triggering the ant task triggering FindBugs2 (as visible in the stack):
ant.java(classname: "edu.umd.cs.findbugs.FindBugs2", inputstring: getSpotbugsAuxClasspath(), fork: "${fork}", failonerror: "true", clonevm: "false", timeout: "${timeout}", maxmemory: "${maxHeap}m") {
Maybe the issue is the empty -auxclasspathFromInput
in
if(!sarifOutput) {
args << "-xml:withMessages=" + tempFile.getAbsolutePath()
}
else {
args << "-sarif=" + tempFile.getAbsolutePath()
}
args << "-auxclasspathFromInput"
args << "-projectName"
args << "${project.name}"
I'm opening a PR to suggest removing this row. While opening the project in Eclipse, I get a stackoverflow:
java.lang.StackOverflowError
at org.apache.maven.plugin.PluginParameterExpressionEvaluator.evaluate(PluginParameterExpressionEvaluator.java:406)
at org.apache.maven.plugin.PluginParameterExpressionEvaluator.evaluate(PluginParameterExpressionEvaluator.java:145)
at org.apache.maven.plugin.PluginParameterExpressionEvaluator.evaluate(PluginParameterExpressionEvaluator.java:432)
at org.apache.maven.plugin.PluginParameterExpressionEvaluator.evaluate(PluginParameterExpressionEvaluator.java:145)
at org.apache.maven.plugin.PluginParameterExpressionEvaluator.evaluate(PluginParameterExpressionEvaluator.java:432)
at org.apache.maven.plugin.PluginParameterExpressionEvaluator.evaluate(PluginParameterExpressionEvaluator.java:145)
at
...
eclipse.buildId=4.25.0.I20220831-1800
java.version=17.0.4.1
java.vendor=Eclipse Adoptium
BootLoader constants: OS=macosx, ARCH=x86_64, WS=cocoa, NL=en_FR
Framework arguments: -product org.eclipse.epp.package.java.product -keyring /Users/blacelle/.eclipse_keyring
Command-line arguments: -os macosx -ws cocoa -arch x86_64 -product org.eclipse.epp.package.java.product -keyring /Users/blacelle/.eclipse_keyring
I also see:
Project build error: Resolving expression: '${java.test.release.version}': Detected the following recursive expression cycle in 'java.test.release.version': [java.test.release.version, java.release.version] pom.xml /spotbugs-maven-plugin line 1 Maven pom Loading Problem
Project build error: Resolving expression: '${java.release.version}': Detected the following recursive expression cycle in 'java.release.version': [java.release.version, java.test.release.version] pom.xml /spotbugs-maven-plugin line 1 Maven pom Loading Problem
Check m2e version, it's been horribly bad for many months. Make sure you run off their snapshot line as it more stable. Currently should be 2.2.x.
Sent from my Verizon, Samsung Galaxy smartphone Get Outlook for Androidhttps://aka.ms/AAb9ysg
From: Benoit Lacelle @.> Sent: Friday, January 27, 2023 2:40:13 AM To: spotbugs/spotbugs-maven-plugin @.> Cc: Jeremy Landis @.>; Comment @.> Subject: Re: [spotbugs/spotbugs-maven-plugin] Parallel build without forking in a multi-module leads to spotbugs getting stuck (Issue #488)
I'm opening a PR to suggest removing this row. While opening the project in Eclipse, I get a stackoverflow:
java.lang.StackOverflowError at org.apache.maven.plugin.PluginParameterExpressionEvaluator.evaluate(PluginParameterExpressionEvaluator.java:406) at org.apache.maven.plugin.PluginParameterExpressionEvaluator.evaluate(PluginParameterExpressionEvaluator.java:145) at org.apache.maven.plugin.PluginParameterExpressionEvaluator.evaluate(PluginParameterExpressionEvaluator.java:432) at org.apache.maven.plugin.PluginParameterExpressionEvaluator.evaluate(PluginParameterExpressionEvaluator.java:145) at org.apache.maven.plugin.PluginParameterExpressionEvaluator.evaluate(PluginParameterExpressionEvaluator.java:432) at org.apache.maven.plugin.PluginParameterExpressionEvaluator.evaluate(PluginParameterExpressionEvaluator.java:145) at ...
eclipse.buildId=4.25.0.I20220831-1800 java.version=17.0.4.1 java.vendor=Eclipse Adoptium BootLoader constants: OS=macosx, ARCH=x86_64, WS=cocoa, NL=en_FR Framework arguments: -product org.eclipse.epp.package.java.product -keyring /Users/blacelle/.eclipse_keyring Command-line arguments: -os macosx -ws cocoa -arch x86_64 -product org.eclipse.epp.package.java.product -keyring /Users/blacelle/.eclipse_keyring
I also see:
Project build error: Resolving expression: '${java.test.release.version}': Detected the following recursive expression cycle in 'java.test.release.version': [java.test.release.version, java.release.version] pom.xml /spotbugs-maven-plugin line 1 Maven pom Loading Problem Project build error: Resolving expression: '${java.release.version}': Detected the following recursive expression cycle in 'java.release.version': [java.release.version, java.test.release.version] pom.xml /spotbugs-maven-plugin line 1 Maven pom Loading Problem
— Reply to this email directly, view it on GitHubhttps://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fspotbugs%2Fspotbugs-maven-plugin%2Fissues%2F488%23issuecomment-1406128560&data=05%7C01%7C%7Cd55894688df24333505108db0039ba40%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C638104020180391910%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=WjoFdD9nETU%2Fyi2Z1N6qxjGQB4SINE2ujJxZ5WM6pNw%3D&reserved=0, or unsubscribehttps://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAAHODIYEHPOOQ2OLL7QU2Y3WUN3V3ANCNFSM6AAAAAAQMNEKU4&data=05%7C01%7C%7Cd55894688df24333505108db0039ba40%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C638104020180391910%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=SUJTKFm6OSeQ7lP3NUPaHF8g%2BFVep1g21M5cancHhR8%3D&reserved=0. You are receiving this because you commented.Message ID: @.***>
Fixed via #535. Will release as soon as I can figure out why I cannot upgrade groovy to 4.0.8/4.0.9 that I need...
This fix is available in spotbugs-maven-plugin 4.7.3.1 Thanks
https://github.com/spotbugs/spotbugs-maven-plugin/issues/488#issuecomment-1406128560
Interesting to see that as a User (i.e. just having a ref to Spotbugs in some project, not opening Spotbugs source in Eclipse), I now also get issues around:
Project build error: Resolving expression: '${java.test.release.version}': Detected the following recursive expression cycle in 'java.test.release.version': [java.test.release.version, java.release.version] pom.xml /spotbugs-maven-plugin line 1 Maven pom Loading Problem
Project build error: Resolving expression: '${java.release.version}': Detected the following recursive expression cycle in 'java.release.version': [java.release.version, java.test.release.version] pom.xml /spotbugs-maven-plugin line 1 Maven pom Loading Problem
m2e is up to date: M2E - Maven Integration for Eclipse 2.1.2.20221130-2239 org.eclipse.m2e.feature.feature.group Eclipse.org - m2e
org.apache.maven.plugin.PluginResolutionException: Plugin com.github.spotbugs:spotbugs-maven-plugin:4.7.3.1 or one of its dependencies could not be resolved: Failed to read artifact descriptor for com.github.spotbugs:spotbugs-maven-plugin:jar:4.7.3.1
at org.apache.maven.plugin.internal.DefaultPluginDependenciesResolver.resolve(DefaultPluginDependenciesResolver.java:133)
at org.eclipse.m2e.core.internal.project.registry.EclipsePluginDependenciesResolver.resolve(EclipsePluginDependenciesResolver.java:47)
at org.apache.maven.plugin.internal.DefaultMavenPluginManager.getPluginDescriptor(DefaultMavenPluginManager.java:182)
at org.apache.maven.plugin.internal.DefaultMavenPluginManager.getMojoDescriptor(DefaultMavenPluginManager.java:286)
at org.apache.maven.plugin.DefaultBuildPluginManager.getMojoDescriptor(DefaultBuildPluginManager.java:244)
at org.apache.maven.lifecycle.internal.DefaultLifecycleExecutionPlanCalculator.setupMojoExecution(DefaultLifecycleExecutionPlanCalculator.java:169)
at org.eclipse.m2e.core.internal.project.registry.MavenProjectFacade.lambda$5(MavenProjectFacade.java:538)
at org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.executeBare(MavenExecutionContext.java:364)
at org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.execute(MavenExecutionContext.java:274)
at org.eclipse.m2e.core.internal.project.registry.MavenProjectFacade.setupMojoExecution(MavenProjectFacade.java:534)
at org.eclipse.m2e.core.internal.project.registry.MavenProjectFacade.getMojoExecution(MavenProjectFacade.java:516)
at org.eclipse.m2e.core.project.configurator.AbstractCustomizableLifecycleMapping.getBuildParticipants(AbstractCustomizableLifecycleMapping.java:69)
at org.eclipse.m2e.core.internal.builder.MavenBuilder$BuildMethod.lambda$1(MavenBuilder.java:110)
at org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.executeBare(MavenExecutionContext.java:364)
at org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.execute(MavenExecutionContext.java:227)
at org.eclipse.m2e.core.internal.builder.MavenBuilder$BuildMethod.lambda$0(MavenBuilder.java:103)
at org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.executeBare(MavenExecutionContext.java:364)
at org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.execute(MavenExecutionContext.java:274)
at org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.execute(MavenExecutionContext.java:213)
at org.eclipse.m2e.core.internal.builder.MavenBuilder$BuildMethod.execute(MavenBuilder.java:86)
at org.eclipse.m2e.core.internal.builder.MavenBuilder.build(MavenBuilder.java:196)
at org.eclipse.core.internal.events.BuildManager$2.run(BuildManager.java:1020)
at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:45)
at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:247)
at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:303)
at org.eclipse.core.internal.events.BuildManager$1.run(BuildManager.java:392)
at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:45)
at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:395)
at org.eclipse.core.internal.events.BuildManager.basicBuildLoop(BuildManager.java:506)
at org.eclipse.core.internal.events.BuildManager.basicBuildLoop(BuildManager.java:454)
at org.eclipse.core.internal.events.BuildManager.build(BuildManager.java:536)
at org.eclipse.core.internal.events.AutoBuildJob.doBuild(AutoBuildJob.java:161)
at org.eclipse.core.internal.events.AutoBuildJob.run(AutoBuildJob.java:255)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:63)
Caused by: org.eclipse.aether.resolution.ArtifactDescriptorException: Failed to read artifact descriptor for com.github.spotbugs:spotbugs-maven-plugin:jar:4.7.3.1
at org.apache.maven.repository.internal.DefaultArtifactDescriptorReader.loadPom(DefaultArtifactDescriptorReader.java:311)
at org.apache.maven.repository.internal.DefaultArtifactDescriptorReader.readArtifactDescriptor(DefaultArtifactDescriptorReader.java:171)
at org.eclipse.aether.internal.impl.DefaultRepositorySystem.readArtifactDescriptor(DefaultRepositorySystem.java:255)
at org.apache.maven.plugin.internal.DefaultPluginDependenciesResolver.resolve(DefaultPluginDependenciesResolver.java:107)
... 33 more
Caused by: org.apache.maven.model.building.ModelBuildingException: 9 problems were encountered while building the effective model for com.github.spotbugs:spotbugs-maven-plugin:4.7.3.1
[ERROR] Resolving expression: '${java.test.release.version}': Detected the following recursive expression cycle in 'java.test.release.version': [java.test.release.version, java.release.version] @
[ERROR] Resolving expression: '${java.release.version}': Detected the following recursive expression cycle in 'java.release.version': [java.release.version, java.test.release.version] @
[ERROR] Resolving expression: '${java.test.release.version}': Detected the following recursive expression cycle in 'java.test.release.version': [java.test.release.version, java.release.version] @
[ERROR] Resolving expression: '${java.release.version}': Detected the following recursive expression cycle in 'java.release.version': [java.release.version, java.test.release.version] @
[ERROR] Resolving expression: '${java.release.version}': Detected the following recursive expression cycle in 'java.release.version': [java.release.version, java.test.release.version] @
[ERROR] Resolving expression: '${java.release.version}': Detected the following recursive expression cycle in 'java.release.version': [java.release.version, java.test.release.version] @
[ERROR] Resolving expression: '${java.release.version}': Detected the following recursive expression cycle in 'java.release.version': [java.release.version, java.test.release.version] @
[ERROR] Resolving expression: '${java.release.version}': Detected the following recursive expression cycle in 'java.release.version': [java.release.version, java.test.release.version] @
[ERROR] Resolving expression: '${java.release.version}': Detected the following recursive expression cycle in 'java.release.version': [java.release.version, java.test.release.version] @
at org.apache.maven.model.building.DefaultModelProblemCollector.newModelBuildingException(DefaultModelProblemCollector.java:197)
at org.apache.maven.model.building.DefaultModelBuilder.build(DefaultModelBuilder.java:568)
at org.apache.maven.model.building.DefaultModelBuilder.build(DefaultModelBuilder.java:454)
at org.apache.maven.model.building.DefaultModelBuilder.build(DefaultModelBuilder.java:267)
at org.apache.maven.repository.internal.DefaultArtifactDescriptorReader.loadPom(DefaultArtifactDescriptorReader.java:293)
... 36 more
I'm keen to open a ticket if this is not specific to myself (e.g. having open spotbugs-maven-plugin in Eclipse previously)
issue fixed now and will be released shortly.
I consider a 50+ multi-module project, with 100k+ java files. When applying spotbugs in our projects, we spend roughly 1 second per project. OK
I'm on the latest versions:
If I run the process with parallelism (e.g.
mvn install -T 8
), our build tends to timeout. I attach a jstack. bug_spotbugs.txtThe main elements are :
The issue seems to occur very frequently (if not always) in our case (as long as the parallelism is high enough).
The main elements of the threaddump: