[Major Change] Move mustache templates into a separate Github project

[wing328]

As discussed with Tony Tam (@fehguy), we want to move the mustache templates into a separate Github project to allow users easily customize the template.

This will be done as part of the 2.3.0 major release.

If anyone has feedback or question, please reply to let us know.

Alternative idea:
What about a command line option to the executable jar that copies the template source files to a local directory \mustache directory for easy modification (so that users do not have to pick it out of the jar file). You can also alter the defaults so that if a \mustache directoy is detected then it is used. With changes like this it becomes trivial for end-users to customize. In addition, if you insert a version number comment in the mustache files and check it when running, you can warn if a new version of the code may require an update to the user maintained mustache files.

[ePaul]

Just one thing to think about.

Often the templates are quite linked to the DefaultCodegen subclass (i.e. they depend on additional properties of the models which are set there).

Moving them into a separate repository can have the effect of an inter-project dependency, where changes have to be made to both of them for the result to still work. This is difficult to review (you don't have one pull request, but two of them, which need to be merged at the same time into different projects) and can cause conflicts if the wrong versions are used together.

(The Ceylon project some time ago changed their multi-repository project to a single-repository one for this reason.)

Alternatively one needs to take special care of compatibility with earlier or newer templates when changing the code (and the other way around). Not sure if automated tests can help here.

(Of course, the same problem already exists with user-supplied templates, so this might be a way of enforcing more stability and documentation of the supported model properties for templates.)

[whq731]

I think maybe the separate project could as a template gallery where anyone can contribute or a plugin project.The major project is the stable built-in template which fully tested.

[fehguy]

The challenge right now is that the DefaultGenerator must stabilize. The templates can move as fast as needed but the base code needs to slow down.

I would like to see that the "engine" has a dependency on template(s) rather than as a monolith. It makes it very scary to update a template library when it has hundreds of commits.

It seems like there could be a single "bundle" for all templates + their respective Java classes (note, the languages/*.java should move to this newly created library as well) or that individual client libraries could be added "a la carte".