Bad advice to remove Groovy extension modules

[Vampire]

Build scan link https://scans.gradle.com/s/npcpjijs3t23e

Plugin version 2.19.0

Gradle version 8.14.3

JDK version 17.0.10

reason output for bugs relating to incorrect advice

------------------------------------------------------------
You asked about the dependency 'org.apache.groovy:groovy-nio:4.0.27'.
You have been advised to remove this dependency from 'testImplementation'.
------------------------------------------------------------

There is no path from root project to org.apache.groovy:groovy-nio:4.0.27 for compileClasspath

There is no path from root project to org.apache.groovy:groovy-nio:4.0.27 for runtimeClasspath

There is no path from root project to org.apache.groovy:groovy-nio:4.0.27 for testCompileClasspath

There is no path from root project to org.apache.groovy:groovy-nio:4.0.27 for testRuntimeClasspath

No compile-time usages detected for this runtime-only dependency.

Describe the bug Libraries from which only Groovy Extension modules are used are advised to be removed.

To Reproduce Steps to reproduce the behavior:

1. Have a project that uses Groovy 4 (either in the main code, or also in test code like when using Spock for tests)
2. Add a (test)implementaion dependency on `org.apache.groovy:groovy-nio:4+"
3. Use the extension module by having in the code for example Path.of("/some/file").eachLine {}

Expected behavior Groovy extension modules should be implementation dependencies when they are used. If Groovy is used in the default duck-typing mode, runtimeOnly would be sufficient to compile, but then the IDE looses the IntelliSense it has for those extension modules as that is only provided for compile-time dependencies. If the respective code is using @TypeChecked or @CompileStatic it is even worse, because then it actually is necessary at compile-time.

I guess the analysis will not really be able to determine whether the extension module is used, without re-implementing the Groovy resolution logic and even then it might be wrong due to the duck-typing and meta-programming capabilities of Groovy.

So maybe the best way would be that if a library contains a Groovy extension module (META-INF/groovy/org.codehaus.groovy.runtime.ExtensionModule), then just accept if it is found in implementation even without it being detected as used by the analysis.

Or maybe a manual configuration like suggested in #1387 would also help here alternatively.

[autonomousapps]

Thanks for the report.

So maybe the best way would be that if a library contains a Groovy extension module (META-INF/groovy/org.codehaus.groovy.runtime.ExtensionModule), then just accept if it is found in implementation even without it being detected as used by the analysis.

This paragraph is very helpful. When this plugin started supporting Groovy, it did so without much in the way of special support for any of Groovy's non-Java capabilities. This was a deliberate choice, since I wasn't sure how many Groovy users I would have. Reports like this help me prioritize improvements.