Atomic templates (no/less xml)

[MikeSchumacherCapgemini]

As a Cobigen user, I want to download as few templates as possible so that i have an easy time figuring out which templates to use.

Users should be able to manually download templates/add template dependencies for the type of project they want to more easily use and develop the templates they actually want.
Additionally, the context.xml file could be taken apart or replaced it with something different so users and developers do not have to sift through the "overstuffed" file to find what they need.

This is a workshop topic, any ideas are welcome and can be discussed in the comments

[hohwille]

My thoughts:

• I thiink we first need to define the new structure of a template archive
  • I would suggest to stay with JAR files that can be put on class/module path (ZIP files might be more natural for other languages but after all CobiGen is written in Java and a JAR is only a ZIP with a different extension).
  • In general we need to figure out which JARs from the classpath are templates and which dont.
  • IMHO the easiest and cleanest way would be to use ServiceLoader that is already established by CobiGen for plugin management. So CobiGen could provide a minimal interface like TemplateProvider that will be called to load the templates (as a composition of increments). Then CobiGen just follows the ServiceLoader pattern to load all registered implementations of TemplatesProvider to find any form of templates and also be a replacement for context.xml as pluggable snippets from code.
  • CobiGen core could already provide abstract base classes for TemplateProvider - e.g.
    • one to load them by scanning the JAR containing the TemplateProvider implementation derived from that base class from a root package templates (replacement for text templates like freemarker or velocity).
    • another one to load language agnostic templates. Here you will have the source code inside the JAR that may again be in the templates folder (to be discussed) and for Java also the *.class files that need to be loaded via regular classloader and we need a namespacing to avoid that two independent template JARs clash by containing the same fully-qualified class name. Maybe we even split macros and templates into separate JARs with maven dependencies between so templates are always text/source for CobiGen and Macros are treated as any other library on the classpath.
    • The nice thing about this approach is that even future ways of how templates can be found and loaded can be addressed in the TemplateProvider implementation giving a lot of flexibility.
• Also we really need to make a choice if we want to create a new CobiGen2 innovation product or if we want to carry the entire compatibility history of CobiGen. Without compatibility it would be relatively easy to fork CobiGen, refactor it to an MVP with the new features and migrate some of our templates to this new world (combined with language-agnostic templates, etc.). When we have reached this point, we could revisit and see if there is a compatibility path or if it is too much effort compared to its value. Otherwise I fear that we will never even reach the state of the MVP as compatibility will slow us down heavily.