Closed abelsromero closed 3 years ago
Seems reasonable, can I ask the use case?
Seems reasonable, can I ask the use case?
The way it is configured now, each model class adds an annotation with the genration timestamp like this:
@javax.annotation.Generated(value = "org.openapitools.codegen.languages.JavaClientCodegen", date = "2021-01-26T14:22:20.823Z[Etc/UTC]")
This makes that even a minimal change in a CRD involves changes to all model classes. This adds steps when reviewing the generated code, for example if you are commiting it and don't want to commit unmodified classes. By adding the option to remove the timestamp (note the current default respects the previous logic) it means that only really modified model classes contain changes.
The change for library
(default value also respect current value) is to users can use other implementations for the api to avoid extra dependencies or just personal preference. Currently it uses okhttp+gson, and for example some users may want to use resttemplate+jackson if they are in a Spring application.
/lgtm /approve
(it's worth noting that there's little compatability between generators, so in practice I suspect that there will be challenges in changing generators, but there's no harm in adding it)
[APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: abelsromero, brendandburns
The full list of commands accepted by this bot can be found here.
The pull request process is described here
Thanks!
(it's worth noting that there's little compatability between generators, so in practice I suspect that there will be challenges in changing generators, but there's no harm in adding it)
In fact I've been seeing that, in this case, this does not affect the generic generator but the custom CRD generator that is only present in JAVA. It's odd however, only Java has that.
This PR exposes the
hideGenerationTimestamp
andlibrary
. Given the limitation for the cli options, I usedh
forhideGenerationTimestamp
andi
forlibrary
.