Discussion: Use of template engine over custom solution

[Nava2]

This is not an issue, but a discussion as I've run into a bit of a road-block in my work.

Currently, the generator is configurable via changing the template values as shown here. The problem I'm having is that I want to add logic into these templates to, for example, generate a new assertion that is only relevant to my classes. If I want to do this, I have to write my own parser logic and call the required templates -- rather than just loading new templates.

I think one of the simplest ways to allow more flexibility is to remove the template engine from the generator and focus on using an existing engine with predefined templates. I believe the primary value of the generator is generating the model of assertions (e.g. ClassDescription) and their associating naming conventions to allow for generating these assertions. We can use this model within another engine to generate assertions

• Apache FreeMarker - tried and true, works easily and is well known. Many features available. Additionally, uses a similar syntax for the "base" templates that we have already (${variable}).
• jtwig - Neat new engine I've not heard of, but looks incredibly nice. Similar feature set
• Thymeleaf - widely used, but I don't think it's well suited to work outside its domain of web generation

Looking for some input in this as I'm unsure if there were previously decisions made or after the fork it was just kept up as legacy. :)

[joel-costigliola]

I'm sympathetic to this idea in 3.0 as long as we keep the templates available to the end user (or let them easily customize the generated code).

Ease of use is important to select a new template engine.

The actual template mechanism has grown organically through time and although proven useful, it is far from a real template engine.

[Nava2]

My thought was to leave the "interaction mechanism" the same, specify you want to change one template type, but they're just more powerful and have access to a bigger object model. For example, no more "property" vs "Property" since you can do "property.capitalize".

[filiphr]

This is linked with #71 a bit. Having a template engine will certainly make it easier to the users with the access to the object model. We are using FreeMarker in another project and it is quite powerful, although we are considering switching to javaparser for different reasons. It also has a good auto complete support in IntelliJ

[Nava2]

@filiphr javaparser is a neat project, but it wouldn't easily allow for textual adjustments. Though, I like the idea of lambdas used to change generation. But that binds it to code which won't work in environments like Maven -- in Gradle it'd be nice since we have "real" code access in-line, but could become overly complicated quickly.

I've also used FreeMarker a bit in the past, I like it, too. It would keep that "textual" requirements (and keeps the barrier for entry lower).

[filiphr]

@Nava2 What I had in mind is not to expose javaparser to the users. They are still going to write the templates as they do it now. It will be used internally to create the java classes. I don't know much about javaparser, but I know that it can read snippets of code (our templates) and convert that to AST which we can then use to populate via the variables that are in the template.