Andrea Peruffo

Hi @iocanel , and thanks for opening this super interesting discussion. I have been tinkering around those things for a while, but couldn't get convinced about one possible implementation and...

> What in comes to types coming from the core kubernetes model (case 1), we could possibly reuse them, as we already do with the buildable references (we use a...

I'm adding an example I'm aware of: https://github.com/Apicurio/apicurio-registry-operator/blob/94d81decf63b5692bde34a35d8a612caff43933f/api/v1/apicurioregistry_types.go#L291 But I agree with your reasoning @iocanel , I think that the question becomes, should we embed this functionality in the `java-generator`...

> we won't be able to use the contextual info I think that we need only class names and shapes, and configuring it with the "original" kubernetes `yaml`/`json` seems appealing....

Hey @iocanel ! Sorry for the slow response, at the moment I'm pretty busy too 🙁 To help this issue move forward what I can commit to do is to...

Fixed in #5844

Hi @thomasdraebing and thanks for filing this issue! I attempted to reproduce your issue [here](https://github.com/fabric8io/kubernetes-client/commit/985cd9fd85530febb05e5d7929581fd497b84293), and I think I'm hitting a slightly different(still not correct) behavior. More specifically, when the...

Thanks for the input! As a general advice, we are moving extensions off of this repo, deprecating them in favor of the java-generator. If KubeVirt is exposing a CRD interface...

Thanks for getting back @iocanel ! > I am really skeptic about moving extensions off this repository as this creates more versions that needs to be aligned, more projects in...

> IMO the only good solution for this is that users actually set up their project with the java generator. This way they keep control of both, the client version...