#158: MVP level 3 for language agnostic templates

[hohwille]

Adresses/Fixes #158 Extends PR #1635

Overview:

• New templates can be found here.
• This is the new ETO template and you can compare it to the devon4j freemarker template.
• The new generators used from the template are here and there while theses are the freemarker marcros.
• IMHO this easily shows the beauty of the new approach with all the benefits: compiler checking, auto-formatting, code-completion, auto-organize imports, refactoring, etc. of templates all come for free and as template developer you can implement templates in the language that you are working with and that you are familiar without then need to learn freemarker or velocity syntax.
• To see all in action including auto-generated imports have a look at my JUnit test.
• I create a new CobiGenModel that shall wrap and replace the ugly Map<String, Object> construct used in CobiGen before.
• To allow typesafe operations on the new model, I created CobiGenVariableDefinitions. IMHO a great improvement compared to the current approach with ModelConstant and ReflectedJavaModelBuilder, etc.
• Language-Support Problem: To follow KISS, I did not go for mmm-code due to the high complexity of maitaining full-fledged parsers for all arbitrary programming languages we might want to support, but also I want to avoid String fiddling and linear out streaming that sucks as you have to loop properties for imports, again for fields, again for getters/setters and once again for equals and finally for hashCode.
• Solution: I created CobiGenCodeBlock as a simple but powerful approach for any kind of file. It is more or less "just" a list of lines for a file. However, it can be hierarchically group and contain meta-data. If there is a bug in the parser and he cannot perfectly detect the code-structure, you still get the code-lines in the order they came from the template. But you can insert additional code (especially) import statements (but also fields, getters, setters, etc.) into these blocks at desired positions.
• The API to interact between generators and these CodeBlocks is CobiGenOutput. If the file is not a programming language (e.g. XML/JSON) the most method will obviously not work.
• With a little but of further work it would be possible to extend my work such that the Java parser reliably detects members (methods) and CobiGenCondiiton will work and allow entire members with JavaDoc, Annotations and Body can be opted-out if a condition does not apply.
• With even more work, we could extract a higher level read API out of CobiGenOutput and extend the parser to allow parsing any file of that language so we finally also replace the mergers with this and solve all from the source-code (that is always the most recent view) rather than on byte-code. Using mmm-scanner could improve the parser to give it a lot more accuracy as the inputs could also be ill-formatted...

Remaining TODOs:

• [ ] decide on final conventions (CobiGen keyword vs. CobiGen__ keyword) and apply it to the code.
• [x] Delete CobiGenAgnosticRegistry and replace with CobiGenGeneratorProvider in core-api using service-loader to find generators and provide access.
• [x] use service-loader to find language specific providers in CobiGenOutputFactory instead of hardcoded hack.
• [x] Move Java related generators (CobiGenGeneratorJava*) to javaplugin that Java templates can use as dependency.
• [x] create a new template module for new devonfw Java templates with fully functional agnostic templates for Java. For simplicity add hand-crafted context.xml / templates.xml
• [ ] consider a small PoC for agnostic generation in different language (C#, TypeScript) to validate the design and get more insights.
• [ ] clarify this TODO with @maybeec or the team. Fun fact: When I implemented CaseSyntax years ago for this feature, I already implemented, what I suggested in the TODO as you can see here
• [x] For the TODOs in generators, I would simply delete the old ones that directly write Java code into the Appendable. BTW: It seems the CobiGen codebase is already full of TODO markers.

@devonfw/cobigen

[hohwille]

Currently I get this error:

[ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.8.1:testCompile (default-testCompile) on project tempeng-agnostic: Compilation failure
[ERROR] /D:/projects/devonfw/workspaces/cobigen/cobigen/cobigen-plugins/cobigen-templateengines/cobigen-tempeng-agnostic/src/test/java/x_rootpackage_x/x_component_x/common/X_EntityName_XEto.java:[14,40] annotation @com.devonfw.cobigen.api.annotation.CobiGenDynamicType not applicable in this type context

However, in Eclipse I do not get these errors. Seems that actually we need Java 17 for this feature. Can someone confirm or come with a different explanation?

[hohwille]

It seems that I only got this annotation compiler error locally. Even better :)

[hohwille]

It would be awesome if someone could give feedback whether my templates structure and config is valid:

• pom.xml (Resources config for structure)
• context.xml
• templates.xml

[hohwille]

And again replaced with new PR #1646