add a parameter for light-codegen for only re-generate code for spec change

[GavinChenYan]

Spec change will only impact:

handler.yml
new handler class
new model class.

Define the parameter as: specChangeOverwriteOnly

[stevehu]

I think we need fine-grained control for the code regeneration. There are two different scenarios for regeneration.

• specification changed with new models or endpoints.
• upgrade frameworks to a new version

The number of files that needs to be overwritten is different in each scenario. We need to add a variable to indicate which case above. I am not sure if a boolean variable specChangeOverwriteOnly is the best option. What if we identify another scenario in the future? Should we define a variable like regenerationReason with a list of enums? Let's discuss it. Thanks.

[ddobrin]

There are indeed multiple scenarios:

• specification change: model might/might not be updated
• upgrade framework and/or dependencies, they can be treated in the same category
• database changes: add support for a database, which can lead to regeneration of the datasource file
• changes in the externalized folder (separate issue already open) which can lead to other regen options

I think that we should move the:
"overwriteHandler": ...,
"overwriteHandlerTest": ...

into a small task list (basing it on enum reduces failures) and we would list tasks as:
regenerateSpec | addDatabase | etc

As I do have some open issues in the codegen, and will revisit some of the code, leave it with me this week and I'll write up a few lines with a proposal.

[GavinChenYan]

For now, lots of our user complain about to use the command line to generate service.
especially in the new project, the spec will change by BSA very frequently. And the develops in the team will re-generate code and change the handler. It will cause code conflict issue as well.

I am trying to add the code generation to maven build which means the code-gen will happen every time project build.

So if there is no change on Spec, it shouldn't have any code change by lighjt-codegen to project.
if spec changed , then the light-codegen will generate required change, for example, new handler class and handler.yml file change.

I think for the first release, we should make this work first (it should easy). And the we can discuss the detail and make it better. I will try to create our maven plugin for this, we can put all config in the config.json to maven config in plugin

[ddobrin]

@ChenYan71 ,
why don't you run the light-bot with a task for an individual API?
In that one, you can set a task to execute a command, which in this case would be your regen.

I don't believe that tying it into a Maven build would be the most beneficial. This would be decoupled.

Initially, as an alternative, as my client has a large number of APIs, I have used a batch file to regenerate all APIs into a sandbox, each time a spec changed.
It regenerates all in one shot

[GavinChenYan]

add temp solution to develop branch:

add new parameter: specChangeCodeReGenOnly

if the indicator is true in the config.json, the light-codegen will not overwrite static config files, like pom.xml, readme.md...

only handler.yml and new handler class will be generated.

We will leave this issue open for whole solution

[ddobrin]

Yes, let's leave it open until we land on a final change.

For my current client, there is a larger API count, and we'll make the change in config.json when we have a finalized version

[stevehu]

When we add anything new to the config.json we need to have meaningful default in the code so that existing config still works.

[ddobrin]

Agreed, as many people will use similar configs and, during an upgrade, might not wish to be impacted by new config options.
Probably defaults should mimic the current behaviour developers are already used to

[ddobrin]

After the recent discussion with @ChenYan71 and @stevehu, and as suggested on Oct 01, I'll add a few lines to the docs for config additions and then make some changes.

This will include:

• ability to generate model only
• ability to bypass the model regeneration
• ability to generate code using arbitrary names for the generation config file, as well as the specification file

[ddobrin]

Modified specChangeCodeReGenOnly to generateCodeOnly - documentation to reflect the change