Quarkus bom should provide io.sundr builder-annotations

[shawkins]

Description

The quarkus platform bom provides the other operator sdk / fabric8 dependencies, so it would be good to include builder-anntations as that is commonly used with custom resources.

cc @manusa

Implementation ideas

No response

[geoand]

cc @iocanel @metacosm

[metacosm]

I'm conflicted on this. On the one hand, it makes sense to manage this dependency since it is used de facto in downstream projects. On the other hand, I feel like this is an internal implementation detail that maybe shouldn't be exposed to end users…

[gsmet]

If it's commonly used with custom resources as mentioned above, it doesn't look like an internal implementation detail?

[metacosm]

If it's commonly used with custom resources as mentioned above, it doesn't look like an internal implementation detail?

To elaborate a little more on my thinking: these annotations can be used to generate fluent builders that follow the same patterns as the client but it's certainly not required to use the client by any means. That said, if people do want to use this, it's probably better that they indeed use the same version as the client's.

However, I would rather not expose this at all if we could help it since it has been a source of problems (see for example the binary compatibility issue that happened recently). Unfortunately, we probably cannot not expose it so it might indeed be better to do it in a "controlled" way via the BOM.

[shawkins]

To do this properly - that is have the dependency come from fabric8 - then we'll either need to remove the provided scope in our pom (and update all of our references to it) or introduce another pom to act as the bom. @manusa are you good with just updating the fabric8 pom have builder-annotations not at the provided scope?

[metacosm]

Wouldn't that mean that the sundrio jar would end up in users' dependencies at runtime, though?

[shawkins]

Wouldn't that mean that the sundrio jar would end up in users' dependencies at runtime, though?

It would be on the user to set the scope to provided - which is what they have to do currently anyway. The difference is that they won't have to manage the version.

[manusa]

@manusa are you good with just updating the fabric8 pom have builder-annotations not at the provided scope?

Sure, no problem.
We just need to ensure all of the references are updated accordingly, which I think you did already in fabric8io/kubernetes-client#6407