kubernetes-client
kubernetes-client copied to clipboard
Introduce BaseHasMetadata class?
Is your enhancement related to a problem? Please describe
This class would provide common implementation for common fields (kind, apiVersion, metadata, maybe addionalProperties?) that are shared by all HasMetadata implementations and might allow for reducing the model class sizes?
Describe the solution you'd like
All HasMetadata implementations would inherit from that base class.
Describe alternatives you've considered
No response
Additional context
No response
It's unfortunately harder than it sounds - the code generation isn't really setup to understand things that are already defined by a base class.
The class would also almost exactly match GenericKubernetesResource - we could consider whether the generic get method makes sense to expose for any resource.
It's unfortunately harder than it sounds - the code generation isn't really setup to understand things that are already defined by a base class.
Yes, looking at what's involved, it's indeed not trivial but should still be doable, I think…
The class would also almost exactly match GenericKubernetesResource - we could consider whether the generic get method makes sense to expose for any resource.
Indeed, a lot of the code could also extracted from CustomResource and put into that base class as well.
I think also that to support this, most of the code should probably be handled via jsonschema2pojo Annotators to be able to generate the needed Java code.
I wanted to spend some time experimenting with the code generation and alternative methods to what we have at the moment. This is one of the multiple goals to achieve. Also the generation of proper Javadoc and field documentation which is something we lack at the moment.
We could also use the Java generator from CRDs…
Well, I don't think that Kubernetes provides CRDs or similar for core resources.
Anyway, my idea is to find an alternative generation method that generates model classes which are backwards compatible with the current ones. Ideally step one would be to generate classes identical to the ones we generate with our current methodology.
Do you have any ideas as to what could be used?
I still need to experiment with it. A customized version of Open Api generator based on something similar to what I did for YAKC. I had a raw idea before summer holidays but I need to refresh it because at the moment I almost completely forgot about the details.
One option could also be to stand up a Kube server and retrieve the CRDs from it and then use the Java generator :)
This issue has been automatically marked as stale because it has not had any activity since 90 days. It will be closed if no further activity occurs within 7 days. Thank you for your contributions!
This issue has been automatically marked as stale because it has not had any activity since 90 days. It will be closed if no further activity occurs within 7 days. Thank you for your contributions!