Am 23.06.2015 23:58, schrieb werickson:
I guess letting groovy do a annotation processor implementation is not
really a solution, is it?
There is a JIRA for this:
https://issues.apache.org/jira/browse/GROOVY-3361
Theoretically it might be possible to wrap a Java Annotation Processor
inside of a Groovy AST, but correctly mapping the helper classes that Java
provides to Annotation Processors seemed difficult when I last looked into
it.
When I talked to Cédric and Guillaume about adding support for Java
Annotation processors to Groovy earlier this year, they suggested the joint
compilation stub approach for getting the Dagger2 annotation processor
working with Groovy.
Actually thinking about this further I see that there is a part that I
don't understand.
Dagger2 is an annotation processor, as such it works on java sources.
Ok, no problem, it can work on stubs. But I thought it will also change
the class generation. As such it should either modify the sources inside
javac or modify the resulting class files on bytecode level. In case 1
it cannot do changes to groovy files, because the stubs are forgotten
later. In case 2 it can still work on precompiled files. Normally
annotation processors do case 1 using the tree api (or even javac
internals). But as I said, this can't work for Groovy, not if the file's
AST itself is supposed to be modified.
So I can see how you can write a module in Groovy to be used by dagger2.
But I fail to see how Dagger2 is supposed to handle a Groovy file with
an @Inject annotation. Can somebody explain?
bye blackdrag
--
Jochen "blackdrag" Theodorou
blog: http://blackdragsview.blogspot.com/
