search

openrewrite / rewrite-templating

Automated templating using code snippets.
Apache License 2.0
16 stars 7 forks source link

Consider merging TemplateProcessor into RefasterTemplateProcessor #48

Closed timtebeek closed 8 months ago

timtebeek commented 11 months ago

What problem are you trying to solve?

Right now we maintain two separate processors, TemplateProcessor and RefasterTemplateProcessor which each produce Java files. These are then stitched together through Semantics, PatternBuilder and reflection. https://github.com/openrewrite/rewrite-templating/blob/022373a047323b6a401d13adc986284f290363ea/src/main/java/org/openrewrite/java/template/internal/PatternBuilder.java#L30-L39

I think originally we had developed these separately with the idea that the generated templates could also be used independent of any generated Refaster recipe. In practice this hasn't happened, and I don't immediately see that happening still.

Describe the solution you'd like

I think we could merge the two into a single processor now and take out the extra generated classes and reflection glue.

Have you considered any alternatives or workarounds?

knutwannheden commented 11 months ago

I disagree. I think there is yet use for the annotation processor we use to process the Semantics calls, when more complex recipes than what can achieved with Refaster are required, yet, either the matching or templating mechanism based on lambdas is still desired. I think we have some examples in rewrite-micrometer.

This being said, I think it could still make sense to basically "inline" the templating processor into the Refaster processor, so we don't have to produce more Java source files. But also this has pros and cons.