Executing 'GradleDependencyReportTask' results in ConcurrentModificationException

[sigee]

Based on this: https://youtrack.jetbrains.com/projects/IDEA/issues/IDEA-351930/Executing-GradleDependencyReportTask-results-in-ConcurrentModificationException

Affected version: 1.15.0+ (1.19.0-rc.2 included)

07:37:59: Executing ':GradleDependencyReportTask'...
Starting Gradle Daemon...
Gradle Daemon started in 1 s 334 ms
> Task :GradleDependencyReportTask FAILED
FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':GradleDependencyReportTask'.
> java.util.ConcurrentModificationException (no error message)

* Try:
> Run with --stacktrace option to get the stack trace.
> Run with --info or --debug option to get more log output.
> Run with --scan to get full insights.
> Get more help at <https://help.gradle.org>.

BUILD FAILED in 12s

Deprecated Gradle features were used in this build, making it incompatible with Gradle 9.0.
You can use '--warning-mode all' to show the individual deprecation warnings and determine if they come from your own scripts or plugins.
For more on this, please refer to <https://docs.gradle.org/8.3/userguide/command_line_interface.html#sec:command_line_warnings> in the Gradle documentation.
1 actionable task: 1 executed
07:38:14: Execution finished ':GradleDependencyReportTask'.

One of the comment at the linked issue, suggests to remove/disable pitest which solved the problem.
Using the older 1.9.11 version also seems fine.

[szpak]

Thanks for letting us know. It would be great to have a minimal problem reproducing the issue.

One more related issue:
https://youtrack.jetbrains.com/issue/IDEA-352344/Pitest-Gradle-Plugin-causes-ConcurrentModificationException-when-running-Dependency-Analyzer

[Vampire]

This indeed is an IntelliJ bug, as it prematurely resolves configurations at configuration time.
It might be questionable that this plugin adds a new configuration - and additionally one without clear role - in the withDependencies action of another configuration, so this could most probably be improved in this plugin too, but either way, that it fails with ConcurrentModificationException (or in latest IntelliJ version with a "Cannot mutate the dependencies of configuration '...' after the configuration was resolved. After a configuration has been observed, it should not be modified." InvalidUserCodeException) is caused by bad IntelliJ Gradle integration code as detailed in the linked issue.

As a reproducer you can use https://github.com/christophsturm/restaurant/, or just apply the pitest plugin to any trivial Gradle build and trigger the "Analyze Dependencies ..." action in IntelliJ.

[ben-manes]

I see the mutate error in the console with Gradle 9.3 when giving pitest a try on Caffeine (buildscan). Also this issue breaks other plugins (ben-manes/gradle-versions-plugin#930) since the configuration fails during evaluatation.

patch

diff --git a/caffeine/build.gradle.kts b/caffeine/build.gradle.kts
index d032c9a3..e6a74e77 100644
--- a/caffeine/build.gradle.kts
+++ b/caffeine/build.gradle.kts
@@ -8,6 +8,7 @@ import org.gradle.plugins.ide.eclipse.model.SourceFolder
 import org.gradle.plugins.ide.eclipse.model.Classpath as EclipseClasspath
 
 plugins {
+  id("info.solidsoft.pitest")
   id("java-library.caffeine")
   id("java-test-fixtures")
   id("jcstress.caffeine")
@@ -398,6 +399,21 @@ testing.suites {
   }
 }
 
+pitest {
+  fun fqcn(name: String) = "com.github.benmanes.caffeine.cache.$name"
+
+  jvmArgs = listOf("-Dimplementation=caffeine", "-Dcompute=sync",
+    "-Dkeys=strong", "-Dvalues=strong", "-Dstats=disabled")
+  excludedClasses = setOf(
+    fqcn("LocalCacheFactory"), fqcn("NodeFactory"),
+    fqcn("SI*"), fqcn("SS*"), fqcn("WI*"), fqcn("WS*"),
+    fqcn("FD*"), fqcn("FS*"), fqcn("FW*"), fqcn("PD*"), fqcn("PS*"), fqcn("PW*"),
+  )
+  excludedTestClasses = setOf(fqcn("MultiThreadedTest"))
+  threads = Runtime.getRuntime().availableProcessors()
+  timestampedReports = false
+}
+
 tasks.named<Jar>("jar").configure {
   from(sourceSets.named("main").map { it.output })
   from(sourceSets.named("codeGen").map { it.output })
diff --git a/gradle/libs.versions.toml b/gradle/libs.versions.toml
index 32a1df17..94bef3ef 100644
--- a/gradle/libs.versions.toml
+++ b/gradle/libs.versions.toml
@@ -82,6 +82,7 @@ osgi-promise = "1.3.0"
 pax-exam = "4.14.0"
 pax-url = "3.0.1"
 picocli = "4.7.7"
+pitest = "1.19.0-rc.3"
 pmd = "7.20.0"
 protobuf = "4.33.4"
 revapi = "1.8.0"
@@ -236,6 +237,7 @@ jmh-report = { id = "io.morethan.jmhreport", version.ref = "jmh-report" }
 jvm-dependency-conflict-resolution = { id = "org.gradlex.jvm-dependency-conflict-resolution", version.ref = "jvm-dependency-conflict-resolution" }
 nexus-publish = { id = "io.github.gradle-nexus.publish-plugin", version.ref = "nexus-publish" }
 nullaway = { id = "net.ltgt.nullaway", version.ref = "nullaway-plugin" }
+pitest = { id = "info.solidsoft.pitest", version.ref = "pitest" }
 revapi = { id = "org.revapi.revapi-gradle-plugin", version.ref = "revapi" }
 sigstore = { id = "dev.sigstore.sign", version.ref = "sigstore" }
 sonarqube = { id = "org.sonarqube", version.ref = "sonarqube" }
diff --git a/gradle/plugins/build.gradle.kts b/gradle/plugins/build.gradle.kts
index 6fbc55ee..621dbee5 100644
--- a/gradle/plugins/build.gradle.kts
+++ b/gradle/plugins/build.gradle.kts
@@ -27,6 +27,7 @@ dependencies {
 
   implementation(plugin(libs.plugins.bnd))
   implementation(plugin(libs.plugins.idea))
+  implementation(plugin(libs.plugins.pitest))
   implementation(plugin(libs.plugins.revapi))
   implementation(plugin(libs.plugins.nullaway))
   implementation(plugin(libs.plugins.sigstore))

[Vampire]

PR #393 should improve this, as it does not use a normal configuration anymore, but a detached configuration to find the platform launcher version which should be more appropriate anyway.

This also fixes the problem with "Analyse Dependencies" in IntelliJ (tested with caffeine).

For the caffeine build it would actually not work sufficiently,
because of the toolchain dependent version downgrade of Jupiter that uses a resolution strategy which would not hit this detached configuration.

But - and that you can also use with rc.3 already - you can configure addJUnitPlatformLauncher = false and add the launcher dependency yourself in your build.
For the caffeine build this will most probably anyway the way to go due to the complex build.