One note I'll add is that while Lombok was presented as an example of a Java annotation processor, it really isn't—it's a monkey-patch of javac itself, as otherwise annotation processors can't modify classes, just add new ones. Regarding "regular" annotation processors, it would be possible to implement the javax.annotation.processing interfaces to resolve from the Groovy AST structures, though this would be decidedly non-trivial.
On Thu, Jun 29, 2023 at 11:57 AM Jochen Theodorou <blackd...@gmx.org> wrote: > On 29.06.23 16:24, Milles, Eric (TR Technology) via dev wrote: > >>> Thanks for raising that issue. It has been a limitation for some folks > for quite a while. I am very keen to improve our joint compilation process > if we can. > >> > >> I was actually wondering if someone really still cares. > > > > > > I do get issues quite often (for groovy-eclipse tooling) that expect > traits, @PackageScope, @TupleConstructor and so on to be cross-compatible > with Java code in the same project. I have experimented with improving the > experience, with some success but also some circular dependency issues. > https://github.com/groovy/groovy-eclipse/commit/9e1f1a753cecba8320da3fba757b7d64cfd091a5 > > I was wondering if groovy-eclipse would actually gain something from a > project in which we first collect Java Class Nodes, then compile Groovy > against them, then compile actual Java against the resulting Groovy > ClassNodes. I do not know how the different phases interact in JDT and > the GroovyCompiler. > > bye Jochen > > >
