Attila Mészáros

@bhellema just released it: https://github.com/java-operator-sdk/java-operator-sdk/releases/tag/v4.2.4 see logging: https://github.com/java-operator-sdk/java-operator-sdk/pull/1737/files

Having some target environment / framework flag probably might help. Also the generator could be integrated. I idea was the same, just the implemented features are not there yet.

> One minor thing I do see in the go client is the notion of a filtering event handler there are filters for such events in JOSDK on top of...

We would need some adaptor/base class, the metadata is always going to be handled the same way since the contents of it never change. I guess HasStatus and HasSpec need...

> I think that this should be possible now by leveraging the [Kube API test module](https://github.com/fabric8io/kubernetes-client/blob/2ccf5587988ee999bf22010235b5c09dbcd2c248/doc/kube-api-test.md). Yes, this should be possible with this. Also you might find this useful: https://github.com/operator-framework/josdk-webhooks

I'm talking about this one field in the annotation, nothing else. So workflow exists, also there is a builder in standalone mode, to create workflow and orchestrate dependent resources. It...

What do you mean workflow does not exists in the domain btw, there is a whole nice section about it, what is a workflow: https://javaoperatorsdk.io/docs/workflows :)

> but there might not be a workflow There is always a workflow create in the background. And even if there is no depends on relations or condition, just two...

These two concepts have clear boundaries. Remember, we have standalone dependents which are independent from workflows. Basically if anybody wan't to implement it's own logic in what order and/or under...

actually might be even good to have a dedicated `@Workflow` annotation as above, for future compatibility.