-
Notifications
You must be signed in to change notification settings - Fork 23
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Unclear distinction between generator modules and codegen application. #23
Comments
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. |
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.
The text was updated successfully, but these errors were encountered: