Unclear distinction between generator modules and codegen application.
From the readme (in progress of reviewing), i'm learning that a few of the folders in this projects more closely resemble sample/example code (for example light-rest-4j), and doesn't necessarily apply to the codegen functionality. It was also a surprise to see light-hybrid-4j, a project which is functionally an api container, to be included in this repo.
Maybe it could be a consideration to split this up into light-codegen-demo, light-codegen, and you already have a light-hybrid-4j, so ... not sure.
These actually generators that are named as the frameworks. For example, light-rest-4j folder contains the generator to generate restful api/services. light-hybrid-4j contains two generators, one to generate light-hybrid-4j server and the other one generate light-hybrid-4j service.
Oh ok ok... my misunderstanding. It's very clear from the code, but the structure of having each generator on the same level as the actual codegen modules threw me. So each time there is a new generator the plan is to add another root level module? Maybe the naming should add a distinction or group them under a single generator submodule?
The reason they are under root folder is due to maven build. These generator can be built from the same parent. I agree that move all generators into a sub folder is much clean; however, it requires to build them separately. Is there anyway we can still group them into a sub folder and they can be built in one shot? Also, I am also thinking how to make this generator customizable. For example, adding/update templates within user's organization etc.
Yeah i don't think it would be too much of a challenge to have submodules building submodules.. i'm sure you remember a certain framework we both worked on building all those nested projects
Yeah I guess it would be a cool idea to have the generator be based on a schema url, that contains paths to all the resources/templates necessary. So every time the generator is run, the latest schemas & templates could be fetched.. is that what you mean?
Yes. I am thinking about this for the docker utility now. Just like the hybrid we can set up a volume so that user can drop their template jar in to override the default one.
Ok, i'll leave that for a separate enhancement issue, and i'll update this one to be specific for the submodule reorganization.
Go ahead. Please create another branch as I am refactoring the templates for light-rest-4j now in develop branch. Thanks a lot for your help.