Possible Sundrio improvements

[shawkins]

https://github.com/sundrio/sundrio/pull/368 will cut down on the model jar sizes by around 20% and will also decrease the runtime footprint.

Other possible opportunities to reduce the size of the generated models:

• suppress the generation of nested builders in places where we're using HasMetadata to represent raw. The available types are usually incomplete as the module and buildable references don't contain all of the types (for example Deployment is missing for Template objects), and the content could actually be free form.
• 6 methods are generated which contain logic for determining the type / builder per nested collection field. It seems like this could be consolidated to a single method for determining the builder - and/or as discussed with @metacosm we could make all of our model objects Editable and omit the instanceof check for types and let the general builderOf logic catch it.
• removeMatchingFromXXX are not necessary as we're already dealing with a VisitableBuilder

@manusa @metacosm @iocanel - do any of these seem worthwhile?

[manusa]

cut down on the model jar sizes by around 20% and will also decrease the runtime footprint

This is awesome.

Making all models "editable" or "cloneEditable", as discussed in the internal meeting seems pretty useful to me. Not only for our Serialization.clone purposes, but in general as a UX improvement.

[shawkins]

Making all models "editable" or "cloneEditable", as discussed in the internal meeting seems pretty useful to me. Not only for our Serialization.clone purposes, but in general as a UX improvement.

Opened #5138 to show what this would look like via the pojo generation logic - this is similar to the lombok toBuilder annotation option.

https://github.com/sundrio/sundrio/pull/376 should make it so that both fabric8 and sundrio can use the same general builderOf logic.

[shawkins]

All of the upstream sundrio improvements have been committed. The generated builders will now be streamlined except for the initil consideration mentioned:

suppress the generation of nested builders in places where we're using HasMetadata to represent raw. The available types are usually incomplete as the module and buildable references don't contain all of the types (for example Deployment is missing for Template objects), and the content could actually be free form.

As users may be using one of the available types, it's not worth addressing at this time.

Once a snapshot or release is available I'll update frabric8 to remove our usage of the fluentimpl.

@manusa @iocanel any additional thoughts on adding an edit, or copy, method directly on the pojos we generate - https://github.com/fabric8io/kubernetes-client/pull/5138

[manusa]

@manusa @iocanel any additional thoughts on adding an edit, or copy, method directly on the pojos we generate

seems fine for me

[stale[bot]]

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!