How to disable new AnnotationProcessor on Groovy code feature?

The recently added APT feature for Groovy code interferes with Jipsy/Gipsy code (mainly the Griffon build). Both projects rely on the same annotations to generate some metadata files, Jipsy does it with APT for Java code only while Gipsy performs the same feat for Groovy code using AST xforms.

When this feature is enabled Jipsy runs on Groovy code and that makes the build fail. Question is then, how can“annotation-processing”-of-groovy-code be disabled?

Stracktrace of failure can be seen at

You should be able to disable it by passing -proc:none to the groovy compile options

I’m sorry but this solution causes other problems down the road with every Griffon project. IMHO the APT-on-Groovy-code feature should be disabled by default and a Gradle specific option to enable it should be added. After all Gradle 2.4 just changed the semantics of the Groovy compiler on its own. Leverage of the APT on Groovy code should be a feature of the Groovy compiler itself, not of the build tool that happens to configure and utilize the Groovy compiler.

What problems?

We added support for annotation processing via the stubs due to an indirect request from the Groovy team. I don’t think there’s much appetite for adding annotation processing support directly to the Groovy compiler.

So you’re looking for a way to joint compile Java and Groovy, apply annotation processing to the Java code but not the Groovy code?

Setting -proc:none on tasks of GroovyCompile seems to disable APT on valid Java sources too, not just stubs. Even if the project code is 100% Groovy code (such as lazybones create griffon-javafx-groovy app) the application fails to run as there are missing metadata files that get should have been generated otherwise.

Well that’s odd. Such solution would require support on other builds tools (such as gmaven-plus, IDEA, Eclipse, etc). It’s weird they requested this feature but decided against adding into core. I just hope this feature is bigger than simply having Groovy work on android.

Exactly. generates metadata files for Java code only, while does with Groovy code. Both tools can work on the same codebase as long as they do not share the same annotation to get the job done, but that’s precisely what you want, i.e, have @ServiceProviderFor be handled in Java and Groovy sources.

Really wishing there was a way to turn this feature off besides using -proc:none. Even better, have it disabled by default.

Annotation processing for Groovy stubs was added as part of supporting 3rd party tools like Dagger 2, which rely on annotations to generate code. By supporting annotation processing on stubs, we allow those tools to work transparently on Groovy classes. There’s no plan to support APT directly in Groovy, just because the AS Ts are too different.

That said, I can see that there are two issues here:

  1. make annotation processing on stubs optional
  2. -proc:none on GroovyCompile should not disable annotation processing on all sources, only on Groovy stubs

Is that correct?

Yup! You hit it right on the nail, as always :wink: with one added thing IMHO

  1. make annotation processing on stubs optional and disabled by default.

@CedricChampeau isn’t your #2 effectively an implementation of #1?

I’m not sold on turning this off by default.

@luke_daley I would say that #2 is a bug. It should be an implementation of #1, but it’s not because it disables annotation processing for all sources (from what Andrés says).

Well, it wasn’t a show stopper before so having it off by default assures behavior compatibility, wouldn’t it?

However, my main concern is to be able to disable it selectively without affecting APT on Java code :smile:

Actually, I think that this…

compileGroovy {
  options.compilerArgs = ["-proc:none"]  

Should disable all annotation processing.

We should disable Groovy only processing with something like this probably:

compileGroovy {
  groovyOptions.annotationProcessing = false
1 Like

+1 this is what I’m looking for :smile:

Created to track this.

1 Like

works like a charm! thank you for providing a fix so fast :smile: