Applying the checker plugin disables other annotation processors

[akbertram]

Rather than add checker to the annotationProcessor configuration, I believe the plugin is replacing the existing package:

          compile.options.annotationProcessorPath = project.configurations.checkerFramework

I have my own annotation processor that is part of our multi-module build and needs to run before checker, otherwise there are missing classes.

Also, specifying the -processor argument to javac disables the auto-discovery process, which means that my annotation processor is not found.

I have worked around this by adding my annotation processor to the checkerFramework configuration, but it would be nice to fix this.

[kelloggm]

Sorry you encountered this issue.

Rather than add checker to the annotationProcessor configuration, I believe the plugin is replacing the existing package:

I think you're right. I'll see if I can fix that right away and make a release.

Also, specifying the -processor argument to javac disables the auto-discovery process, which means that my annotation processor is not found.

This is, unfortunately, a fundamental problem. Because the Checker Framework provides many annotation processors and expects users to specify which ones to use, it is fundamentally incompatible with annotation processors discovered through javac's annotation processor discovery phase.

One option to fix that issue would be to re-implement that process in the plugin and then specify the processors that would have been run automatically. For now, manually specifying the processors you want to run will remain the workaround.

[akbertram]

Thanks for the quick response. Perhaps the plugin could just add checker to the annotationProcessor configuration rather than declare a new configuration? Unfortunately I don't think gradle provides a standard way to declare processors, so adding my other annotation processsor as a "checker" is an acceptable solution. Thanks!

…

On Thu, Jul 18, 2019, 7:11 PM Martin Kellogg ***@***.***> wrote: Sorry you encountered this issue. Rather than add checker to the annotationProcessor configuration, I believe the plugin is replacing the existing package: I think you're right. I'll see if I can fix that right away and make a release. Also, specifying the -processor argument to javac disables the auto-discovery process, which means that my annotation processor is not found. This is, unfortunately, a fundamental problem. Because the Checker Framework provides many annotation processors and expects users to specify which ones to use, it is fundamentally incompatible with annotation processors discovered through javac's annotation processor discovery phase. One option to fix that issue would be to re-implement that process in the plugin and then specify the processors that would have been run automatically. For now, manually specifying the processors you want to run will remain the workaround. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#20?email_source=notifications&email_token=AADO5Q5WLAJLMCB2NDNPVP3QACP5RA5CNFSM4IE3DCI2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD2JFFEQ#issuecomment-512905874>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AADO5Q2HZWSZXBLFHCYT7HLQACP5RANCNFSM4IE3DCIQ> .

[msridhar]

So is the current status still that if your build uses other annotation processors, those need to be added as checkers in order for them to still run after applying this plugin? That is going to painful for users of tools like AutoValue, which runs multiple annotation processors internally that are defined in a manifest file.

Maybe the plugin could support not specifying any checkers, which would mean that custom checkers that include a relevant manifest file would still be run? It's not a general solution, but it would support our current use case.

[msridhar]

Slightly crazy idea @kelloggm. How about instead of using the -processor argument, the plugin generates a META-INF/services/javax.annotation.processing.Processor file (as described here) to a new temporary directory, and then sticks that new temporary directory in the processor path for the build? I just did some tests and this should work just by placing the config file in a temp directory, without generating a temporary jar file each time. This should make the plugin compatible with processor auto-discovery, hopefully?