#158: MVP level 1 for language agnostic templates

Adresses/Fixes #158 Extends PR #1632

Features/Changes:

To get started have a look at the simplified working ETO-Template that is already covered with a JUnit where you can see that also field, getter and setter generation is actually working.
If we wanted to support really advanced generation without implementing generators and keeping more control in the template itself, I have created a really cool but maybe a little crazy example here that is surely not yet supported.
In case we want to stay with streamed writing and character fiddling but more control over import statements I also created this variant where we can express the difference between qualified and simple type names and get control of manual import declaration (however, IMHO we could only place the For-Each in a comment above the import statement then). So IMHO we should go for either KISS (streamed writing and character fiddling) or we go for a complex AST based approach and then we should use the higher-level AST and auto-generate imports, getters and setters without the need to implement this explicitly in templates so this 3rd alternative is not the way I would recommend to go. I am just exploring and trying to raise fantasy for what is possible in the future.
I created a new (agnostic) template engine as cobigen-plugin that allows to resolve variables as described in #158 and also strips out all lines containing the keyword "CobiGen" (case-sensitive).
If those lines reference a code generator (and are not import statements), that generator is executed. So far only PoC - would need a reasonable registry and lookup mechanism.
Introduced CobiGenModel. On the long run, I would love to replace all these ugly Map<String, String> or Map<String, Object> constructs with CobiGenModel. Further I would love if all ModelBuilder's and InputReader's would receive an instance of CobiGenModel and would set its data into that model rather than creating Objects and Maps that later need to be checked with instanceof and casted and merged, causing really messy code.
To allow type-safeness on a generic model, I introduced CobiGenVariableDefinition with currently a central place where all could be defined in CobiGenVariableDefinitions (to be replacing all ModelConstnat classes in CobiGen). Surely to be discussed if we want to have these declarations centrally in the API or more modular. However, not only language plugins but also language merged and templating engines may need to share model variable definitions and putting them centrally is the easiest starting point.
I created the enum VariableSyntax as a nice encapsulation of the supported variable syntax available with all the specific tricks that come with it (including legacy support).
I created annotations for templates like @CobenGenTemplate, @CobiGenTemplateCondition, @CobiGenDynamicType, and @CobiGenForEach. Especially the dynamic-type construct needs a lot of further discussion. See example here.
I have created various templates for modern java crud played around with different ideas and variants for advanced dynamic edge-cases. IMHO it now gets really clear what we can archive on a simple level of String/Writer fiddling where we have to stream content sequentially and therefore have to loop the same things redundantly 3-4 times (for imports, fields, getters, and setters) compared to an AST based approach like with mmm-code as alternative/addition for specific supported languages. I would also love to see @CobiGenTemplateCondition being supported but this would IMHO require an AST based approach as you have to be aware of the language context to decide what to exclude if the condition does not apply (e.g. Javadoc above, method signature and body below). However, I am already quite surprised, that with so little work I could already make so much of the average generation case work. I we want to stay with KISS, we could also think about making optional boundaries with begin and end markers instead. Surely not nice but simple to implement then.

Concerns/drawbacks:

I am pretty aware that "polluting" the cobigen-api with tons of Java specific generators is an odd hack.
Also the templates that I have created in the template-engine would belong to a real templates project (e.g. cobigen-templates-devonfw-java).
I still also have some C&P leftovers from velocity template-engine, JUnit coverage is insufficient, TODOs are present, JavaDoc incomplete, etc.

However, I already archived way more than I hoped and expected in that short time I have invested. Also the general CobiGen archicture seems quite flexible and extendable allowing me to do all this...

@devonfw/cobigen

devonfw / cobigen

#158: MVP level 1 for language agnostic templates #1634