Enhanced ruleset fails to find AST transform processor classes

[pshevche]

Description

The latest milestone of the Spock framework has added a couple of annotation-driven AST transforms that started causing CodeNarc warnings if an enhanced ruleset is used (see original issue). The issue does not seem to be Spock-related, as I was able to reproduce it in a standalone project that has a no-op annotation transform. We'd appreciate your input on what may be causing this issue and if there is any workaround we can apply apart from removing the enhanced ruleset.

How to reproduce

1. Check out https://github.com/pshevche/spock-reproducers/tree/main/issue-2149_codenarc-enhanced-rules-ast-transform
2. Run ./gradlew :lib:codenarcTest --rerun-tasks
3. Observe that the output contains the following warning (Build Scan):

WARNING: Compilation error for non-default compiler phase (semantic analysis). Consider removing "enhanced" rules from your ruleset.
Compilation failed for [CustomCompilerPhaseSourceDecorator[SourceFile[/Users/pshevche/dev/spock-reproducers/issue-2149_codenarc-enhanced-rules-ast-transform/lib/src/test/groovy/org/example/SomeTest.groovy]]; phase=4 (semantic analysis)]; org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed:
None: Could not find class for Transformation Processor org.example.transform.DummyTransform declared by org.example.transform.ApplyDummyTransform

Analysis

I have stumbled upon this issue groovy/groovy-eclipse#270 in groovy-eclipse, where a similar issue was reported. I followed the recommendation from that issue and moved the transformation processor to a new module, but that did not help. The warning was still emitted.

[chrismair]

I'm wondering if this is encountering that "chicken and egg" problem of needing the transformation class file already built when compiling the rest of the code, as described in:
Groovy Classpath issue - Help/Discuss - Gradle Forums
and Custom AST transformation classes broken · Issue #270 · groovy/groovy-eclipse

If that is the case, then I think that would involve building the transformation separately and supplying that to the classpath for CodeNarc.

Now I understand that the original problem was using Spock annotations and transformations, in which case those class files should already be built. So in the original issue, were the Spock jars also added to the CodeNarc classpath? If not, please try that.

[pshevche]

Sorry for a delayed response.

were the Spock jars also added to the CodeNarc classpath

Yes, they were. If the JARs are not on the classpath, then even more warnings are triggered, because classes like Specification will not be found. But once Spock JARs are added to the classpath, then only transformation processor classes will not be found.

[chrismair]

Until we get this resolved, the workaround is to not include (or exclude) any rules from the "enhanced" ruleset.

[chrismair]

Also, that link in #1 How to Reproduce section of the description is no longer valid. (understandable since it has been several months).

[dlehammer]

Hi @chrismair ,

Regarding

Until we get this resolved, the workaround is to not include (or exclude) any rules from the "enhanced" ruleset.

And

SNIP.. Consider removing "enhanced" rules from your ruleset.

In my experience, the symptom described is also triggered by the rulesets/serialization.xml, excluding "enhanced" & "serialization" rulesets silences the symptom.
I suggest the error message is amended to reflect that, in-order to aid CodeNarc enthusiasts 🤓

[chrismair]

Good point @dlehammer .

In this case, I should not have said exclude just the "enhanced" ruleset, but rather all enhanced rules, as listed in:
CodeNarc - About the Enhanced Classpath Rules

Unfortunately, that includes all the the "enhanced" ruleset, as well as some other rules contained in other rulesets, including the NonSerializableFieldInSerializableClass rule in the "serialization" ruleset.