Giters

openrewrite / rewrite-templating

Automated templating using code snippets.

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Split annotation processor from refaster converter

Bananeweizen opened this issue · comments

commented

What problem are you trying to solve?

I've just written a custom rewrite module with several refaster templates in Eclipse, and built it with Maven, which was quite some adventure (but it was far less complicated than getting the original refaster engine to work in an OSGi context with ECJ some years ago). While I was wondering if I might be able to debug even the annotation processor with that setup, it occurred to me that it should not be necessary to debug through the annotation processor interface.

Describe the solution you'd like

Split the annotation processor into 2 classes:

  • one just fulfilling the annotation processor interface of the compiler, then delegating
  • one doing only the parsing and conversion of refaster templates, useable from the annotation processor or standalone

If I get it right, the annotation processor already converts the input to its own AST representation at the root level (the compilation unit), so the parsing should already be independent of the APT interface.

This would have two benefits:

  • tests could be written without invoking the compiler
  • debugging would be possible without the annotation processing being involved.

Or do I miss something obvious that prohibits this separation?

commented

Hi @Bananeweizen ; Neat to hear how you're applying the tools! Can't say this usage was foreseen, but that makes it all the more fun to hear about.

You're right in calling out that currently there's no clear separation between the annotation processor and the conversion of refaster templates to rewite recipes. I'm not sure how easy that separation would be, given that we use com.sun.tools.javac liberally throughout the code. While we're open to explore the option, there's also some ongoing efforts in #57 to reuse TemplateCode and elsewhere to support generics. Might be best to coordinate such that there's no conflicts with any work you might plan to do.

commented

Thanks for the explanation. In that case I'll close this ticket, because the other restructuring tasks have more important benefits.

commented

Welcome to revisit this once the other features have landed! Always nice to see if tools can be used in multiple ways, and a better separation would help the code quality as well.