In general, I'd try to move away from Pluralize and rely on the real API plural which differs from the output of Pluralize.toPlural on many occasions.

In general, I'd try to move away from Pluralize and rely on the real API plural which differs from the output of Pluralize.toPlural on many occasions.

I agree but there are cases where you don't get a choice and you'd still want to get the default plural version that is computed by Fabric8, without having to know how it's done. That's why it's called default, btw, not simply plural because it might indeed differ from the actual plural form.

I agree but there are cases where you don't get a choice and you'd still want to get the default plural version that is computed by Fabric8, without having to know how it's done. That's why it's called default, btw, not simply plural because it might indeed differ from the actual plural form.

What we want is precisely to get which cases are these so that we can avoid them altogether.
For v7, it would be nice if we could get rid of all of this.

Do you have any examples of which cases might these be?

I agree but there are cases where you don't get a choice and you'd still want to get the default plural version that is computed by Fabric8, without having to know how it's done. That's why it's called default, btw, not simply plural because it might indeed differ from the actual plural form.

Do you have any examples of which cases might these be?

When you're dealing with GenericKubernetesResource and need to get the plural form associated with the GVK to deal with RBACs for example. Ideally, you'd get the plural from the resource class but you might not have the resource class, only the GVK.

Ideally, you'd get the plural from the resource class but you might not have the resource class, only the GVK.

Right now we should be doing that by querying the cluster for the exposed resources just like kubectl does.

Ideally, you'd get the plural from the resource class but you might not have the resource class, only the GVK.

Right now we should be doing that by querying the cluster for the exposed resources just like kubectl does.

I agree that would be the appropriate solution but it's just not possible when you perform that processing at build time and/or you might not be connected to the target cluster.

but it's just not possible when you perform that processing at build time and/or you might not be connected to the target cluster.

Why would you need the plural at build time or when not having direct access to the cluster?

From an operator generation context you should have that already available in the CRD. From any other context, I can't think of why would you need the plural.

but it's just not possible when you perform that processing at build time and/or you might not be connected to the target cluster.

Why would you need the plural at build time or when not having direct access to the cluster?

To generate RBACs which happens at build time. More specifically, when the user is using GenericKubernetesResource for secondary resources, the processor might only get the GVK for the resource, in that case, the plural needs to be inferred from the kind only.

To generate RBACs which happens at build time. More specifically, when the user is using GenericKubernetesResource for secondary resources, the processor might only get the GVK for the resource, in that case, the plural needs to be inferred from the kind only.

Do you have an example or test in the JOSDK repo(s). For me it's still hard to see how the user might have (and provide) the info for the external resources and not be able to manage the plural (how is this dealt with in the regular OSDK? and so on)

To generate RBACs which happens at build time. More specifically, when the user is using GenericKubernetesResource for secondary resources, the processor might only get the GVK for the resource, in that case, the plural needs to be inferred from the kind only.

Do you have an example or test in the JOSDK repo(s). For me it's still hard to see how the user might have (and provide) the info for the external resources and not be able to manage the plural (how is this dealt with in the regular OSDK? and so on)

For some more context, see the discussions at operator-framework/java-operator-sdk#2515.
For QOSDK, more specifically, see https://github.com/quarkiverse/quarkus-operator-sdk/pull/937/files#diff-b780cb662fc5c0a824655ac29ced7dca9efd35a33f771cd3f3a84a46f21b7cebR134-R147. When QOSDK processes the dependent resources (secondary resources), it's at a point where the user might not have provided the plural form (if they even knew about it) and since happens at build time, checking the API server would be meaningless.