Transitive dependency on bucket4j

[alastair-donlon-lb]

Describe the bug
I have a number of services which are built on top of Spring Kubernetes Client, and thus Kubernetes Java Client and the client-java-extended dependency which has a dependency on bucket4j. We also use bucket4j. However, we are using 8.14 of bucket4j which has a different Maven coordinates than either 7.6.0 (the version pulled in by v 19.0 of the client) or 8.10 (which latest is using) and now incorporates a JDK target number in the artifact name. So we end up with 2 conflicting versions of the library on our classpath, which can lead to confusion.

Client Version
19.0.1

Kubernetes Version
v1.32.1 (EKS)

Java Version
Java 21

To Reproduce
Steps to reproduce the behavior:

Expected behavior
Ideally, there should not be a conflict between different versions of transitive dependencies, and a consumer's option to update to a newer, backwards compatible version of the dependency should allow existing libraries with a transitive dependency to work with the updated version. In the event of artifact coordinates changing this contract breaks and multiple versions of the dependency end up on the classpath, with classpath ordering becoming the differentiating factor, which can lead to an older version of the dependency shadowing the newer version. In these situations perhaps some form of shadowing could help protect clients from the impact of the coordinate change? Given the direction of bucket4j moving forward it would seem this is more and more likely to be an issue as a JDK version is being used as part of the artifact name.

[brendandburns]

This seems to me like a Maven/Java dependency problem unrelated to this library.

If there are things that we can do in our pom.xml to make this easier to resolve, please feel free to send PRs.