Code10x
Build toolshard5-8 years

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?

Maven and Gradle apply genuinely different default rules when two paths in the dependency graph request different versions of the same artifact. Maven's rule is nearest wins: whichever declaration sits closest, by depth, to the project's own POM is kept, regardless of whether it's newer or older. Gradle's default is the opposite: highest wins — it compares the requested versions directly and keeps whichever one is numerically greater, with no regard for how deep in the tree it was requested from. The same set of declared dependencies can walk the same graph and still land on two different resolved versions, because the two tools aren't asking the same question when they hit a conflict — one asks "which declaration is closer," the other asks "which version is bigger."

The lesson behind it →
PreviousA 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?Next 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?
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 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?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`?