[Investigation] Handle Annotation Processing for Test Compilation When Other Processors Present

[bmarcaur]

Related to #769

I am similarly experiencing issues when attempting to index particular internal repositories. When running scip-java index I am seeing the following error:

Execution failed for task ':log-receiver:compileTestJava'.

> Compilation failed; see the compiler output below.                                                                           error: plug-in not found: semanticdb

Taking a closer look at the build scan I noticed that all of the compileJava tasks were succeeding. I used that information to isolate the compileTestJava. I patched in a small change that appended --debug to the Gradle invocation launched by SCIP. I was able to use this to print out the arguments being passed to javac. The most glaring difference was that my test compilation was using -processorpath for an alternative annotation processor (ErrorProne).

Which, according to the javac documentation, -processorpath "Specifies where to find annotation processors. If this option is not used, then the class path is searched for processors." Which led me to question whether it just so happened that we were only adding a competing annotation for the test configurations.

Hence my change. Piggybacking on the annotation mutation when it is discovered that the annotation path is present, we now also append the semanticdb-plugin to the testAnnotationProcessor similar to how it appends to the compileOnly and testCompileOnly configurations.

Note

I am still not 100% certain that this is the absolute root cause, but in making this small change I was able to successfully produce a SCIP index for a repo that previously used to fail.

Test plan

As of right now this is a simple before and after within a failing repository. That repository is private, but I am willing to put a minimal repro together if it will help build confidence.