Working on the new Gradle plugin for building Jenkins plugins, I needed to process Groovy source for JSR-269 annotations. In the Maven builds for Jenkins plugins written in Groovy, we do a gmaven generate-stubs call and then compile, which seems to do the trick. But even with a placeholder Java class added to src/main/groovy to ensure that joint compilation would be used, the temporary stubs weren’t being processed. I managed to get things working by doing stub generation via the generatestubs ant task (see https://github.com/jenkinsci/gradle-hpi-plugin/blob/master/src/main/groovy/org/jenkinsci/gradle/plugins/hpi/StaplerGroovyStubsTask.groovy), adding the output path to the Java source dirs and making sure this happened before the Java compile ran, but this seems…hackish at best. Any suggestions?
Gradle’s GroovyCompile task is based on the groovyc Ant task, which (in contrast to GMaven) treats generated stubs as an internal implementation detail of joint compilation. I think that by now it’s possible to configure the Ant task to keep the stubs (mainly for debugging), but you’d have to research this yourself or ask the Groovy folks.
Alternatively, is there a chance that you can do the annotation processing via reflection (or ASM)?
The Ant task does allow keeping the stubs, but GroovyCompile doesn’t allow configuring that option - you’ve got GRADLE-1743 open for that. =)
I honestly don’t know vis a vis reflection/ASM - I’ll check on that. Like I said, what we’ve got now is working, and allows us to use the JSR-269 javac stuff for Groovy and Java on both Gradle and Maven, which is a big plus given that every Jenkins plugin in Groovy or Java up until now has been built with Maven.
I’ve now added stubDir and keepStubs configuration options. But according to the documentation, the groovyc Ant task doesn’t honor them when running in fork mode, which is the default in Gradle. You can however turn off forking. I’ll need to look a bit more into this.