Code10x
Build toolssenior8+ years

A security review asks the team to prove that a specific jar deployed to production was built from a specific commit, byte for byte. What three things does the project need to have in place for that proof to actually be possible, and why does each one matter?

Proving a jar came from an exact commit requires the build itself to be reproducible — the same commit has to produce byte-identical output every time it's built, on any machine — and that needs three separate things working together, not just one. First, the wrapper (./mvnw/./gradlew) pins the build tool's own version, so a different Maven or Gradle installed on the reviewer's machine, or on a different CI runner, doesn't silently change how the build behaves. Second, every dependency version has to be pinned — no version ranges, no snapshots — because those can resolve to different jars on different days even from the identical POM, which defeats reproducibility regardless of the tool. Third, the artifact's own build needs a fixed, deterministic timestamp (project.build.outputTimestamp in Maven) rather than "the moment the jar was built," because a jar's zip entries normally embed the build time, and two builds of the same source at two different moments would otherwise produce different bytes purely from that timestamp, even with identical content. All three together are what make a checksum of the shipped jar actually provable against the source commit.

The lesson behind it →
PreviousA team migrates a service from Maven to Gradle, keeping the same declared dependency versions. A transitive dependency that resolved one way under Maven resolves to a different version under Gradle, and a test that passed before now fails. Why would the same declared dependencies produce two different classpaths?Next A parent POM lists three modules — `orders-domain`, `orders-api`, `orders-worker` — with no explicit build order given anywhere. How does Maven decide what order to build them in, and what stops a developer from accidentally importing `orders-api` classes into `orders-domain`?
More on Build tools
A service compiles cleanly, but throws `NoSuchMethodError` in production on a code path that calls into a third-party library the team never directly wrote a version for. Where would you look first, and what's the actual mechanism that produces this?A project imports the Spring Boot BOM, and a developer bumps just the Spring Security version by hand to pick up a patch, leaving the rest of the BOM's versions alone. Soon after, the app fails to start with a confusing bean-wiring error. What did the BOM actually provide, and what did overriding one version break?A team migrates a service from Maven to Gradle, keeping the same declared dependency versions. A transitive dependency that resolved one way under Maven resolves to a different version under Gradle, and a test that passed before now fails. Why would the same declared dependencies produce two different classpaths?A parent POM lists three modules — `orders-domain`, `orders-api`, `orders-worker` — with no explicit build order given anywhere. How does Maven decide what order to build them in, and what stops a developer from accidentally importing `orders-api` classes into `orders-domain`?