denis256 notes and projects

The kubernetes-client/java project, the Java client library for Kubernetes, had a small dependency refresh this week that is still worth reading if you ship it inside services. The headline change is an AWS SDK for Java 2 patch bump from 2.46.18 to 2.46.20, followed by a Bazel sync so Maven and Bazel builds resolve the same artifacts.

What changed in this narrow window

Only two commits are in the window, both from July 2, 2026. That matters because there is no API surface to retest for signature drift. The useful work is in dependency resolution and build parity: the maintainers bumped the Maven AWS SDK group in pom.xml, then synced the Bazel dependencies in MODULE.bazel and maven_install.json.

This is mostly maintenance. Still, dependency maintenance in a Kubernetes client can matter more than the diff size suggests. A client library often sits in controllers, operators, internal platforms, and small automation tools that nobody wants to debug at 02:00 because an auth jar moved out of line.

AWS SDK bump touches auth paths

The Maven change is one property: aws.sdk.version. That property feeds direct production dependencies for software.amazon.awssdk:sts, auth, http-auth-aws, http-auth-spi, http-client-spi, and utils. For users, this is not a new feature. It is maintenance in the code that talks to AWS identity plumbing, mainly STS and request auth.

If your Java client runs inside EKS or any setup that obtains Kubernetes auth through AWS credentials, this is the dependency line to notice. A patch bump should be low drama, but auth libraries are where subtle classpath conflicts show up first. The important detail is that the project changes the shared version once, not each artifact by hand.

The direct artifacts moved together:

• software.amazon.awssdk:sts
• software.amazon.awssdk:auth
• software.amazon.awssdk:http-auth-aws
• software.amazon.awssdk:http-auth-spi
• software.amazon.awssdk:http-client-spi
• software.amazon.awssdk:utils

A quick check in downstream builds is enough:

mvn -q -DskipTests dependency:tree -Dincludes=software.amazon.awssdk

Maven remains the single version source

The changed pom.xml is almost boring, which is good. The project already centralizes dependency versions in properties, and this commit keeps that pattern. It means child modules do not need separate AWS version edits.

That matters in this repo because the root POM manages modules such as util, kubernetes, extended, fluent, spring, and spring-aot. When an optional dependency like software.amazon.awssdk:sts is managed in one place, consumers can choose it without guessing which patch line the project tested against.

Operators do not need config changes. Contributors do need to keep the direction clear: update the POM first, then let generated build files follow. Manual edits to generated sections are how small dependency bumps become tedious review noise.

Bazel lock sync keeps alternate builds honest

The Bazel sync is the larger diff by line count, but it is mostly generated lock data. MODULE.bazel updates the six direct AWS artifacts listed in the generated Maven install block. maven_install.json then updates resolved transitive AWS modules and their jar checksums.

That split is important. A Maven only change would leave Bazel users behind. A Bazel only change would fork dependency truth. This pair keeps the two build systems aligned, which is exactly what a dual build Java repo should do.

Most of the noisy JSON churn is expected. The lock file includes artifacts like aws-core, regions, sdk-core, netty-nio-client, and third-party-jackson-core. Those are transitive pieces pulled by the direct AWS SDK modules. The commit does not claim a behavior fix. It says the resolved graph changed, and records checksums so Bazel can reproduce it.

How to prepare

Because this is auth adjacent, test actual credential flows rather than only compile. In a Java service that uses the client against EKS, run the path that loads kubeconfig, resolves AWS tokens, and performs a simple API call. For libraries, at least run dependency convergence checks with your existing BOMs.

Useful checks:

• mvn dependency:tree for duplicate AWS SDK versions
• Bazel build and tests if your fork uses Bzlmod
• One real call through ApiClient, not only unit tests

Also watch classpath pins. If an application already forces a different AWS SDK patch through a parent POM or platform, this update may not be the version your runtime actually uses. That is not the project’s fault. It is the usual Java dependency bill arriving with a stamped envelope.

Treat this as a low risk dependency refresh, with one caveat: auth dependency bumps deserve runtime checks. For most users of kubernetes-client/java, there is no code change to make. Pull the next artifact, run existing integration tests, and pay attention to EKS and STS paths.

Contributors should copy the maintenance pattern. Change pom.xml first, run the sync that updates MODULE.bazel and maven_install.json, and keep generated lock churn in the same PR. Splitting those steps makes reviewers inspect a broken intermediate state.

Nothing in this window suggests a release level migration. The practical takeaway is simpler: the project is keeping AWS auth dependencies fresh while preserving Maven and Bazel parity. That is not glamorous work. It is the kind that prevents future support tickets from becoming archaeology.