Dependency management and supply-chain safety

Dependency management is deciding which libraries a project uses and which exact version of each one ends up on the class path, including the libraries that those libraries bring with them. Supply-chain safety is making sure that every one of those files is the file its authors published, and that none of them has a known vulnerability, on every build. Both matter because a project that declares two libraries can receive a dozen. When two of them need different versions of the same library, the build tool keeps one, and Maven and Gradle choose by different rules. A wrong choice compiles, passes the tests and fails in production, or brings back a version with published security advisories. Look at the tree whenever you add or upgrade a dependency, and look up its versions whenever a new advisory appears.

This lesson builds one small system with Apache Maven 3.10.0 and Gradle 9.7.1 on Eclipse Temurin 25.0.4.1. Two in-house libraries, published by other teams into a company repository, were built against different versions of the JSON library jackson-databind. A billing application uses both. Its Gradle builds are written in Gradle’s Groovy DSL, build.gradle, which drives the same API as the Kotlin DSL of the previous lesson.

One tree, two answers

legacy-audit 1.4.0 needs jackson-databind 2.13.2 and invoice-json 2.0.0 needs 2.22.3. Both requests sit two levels below the application, and its class path can hold only one jackson-databind:

<?xml version="1.0" encoding="UTF-8"?>
<!-- The billing application: it uses both in-house libraries and never names Jackson itself. -->
<project xmlns="http://maven.apache.org/POM/4.0.0"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 https://maven.apache.org/xsd/maven-4.0.0.xsd">
  <modelVersion>4.0.0</modelVersion>
  <parent>
    <groupId>com.example</groupId>
    <artifactId>company-parent</artifactId>
    <version>1.0.0</version>
    <relativePath>../company-parent/pom.xml</relativePath>
  </parent>
  <artifactId>billing-app</artifactId>
  <version>1.0.0</version>

  <repositories>
    <!-- The company's repository, where the in-house libraries are published. -->
    <repository>
      <id>company</id>
      <url>file:${project.basedir}/../repo</url>
    </repository>
  </repositories>

  <dependencies>
    <dependency>
      <groupId>com.example</groupId>
      <artifactId>legacy-audit</artifactId>
      <version>1.4.0</version>
    </dependency>
    <dependency>
      <groupId>com.example</groupId>
      <artifactId>invoice-json</artifactId>
      <version>2.0.0</version>
    </dependency>
  </dependencies>
</project>

// The same billing application, built by Gradle from the same sources (Groovy DSL).
plugins {
    id 'application'
}

group = 'com.example'
version = '1.0.0'

java {
    toolchain {
        languageVersion = JavaLanguageVersion.of(25)
    }
}

repositories {
    // The company's repository, where the in-house libraries are published, then Maven Central.
    maven {
        name = 'company'
        url = uri('../repo')
    }
    mavenCentral()
}

dependencies {
    implementation 'com.example:legacy-audit:1.4.0'
    implementation 'com.example:invoice-json:2.0.0'
}

application {
    mainClass = 'com.example.billing.Main'
}

#!/bin/sh
# Publishes projects into the file repository repo/ beside this script, the way a release build publishes them into
# a company's repository manager. With no arguments: the parent POM and the two in-house libraries.
set -e
cd "$(dirname "$0")"
repo="file:$(pwd)/repo"
[ $# -gt 0 ] || set -- company-parent libs/legacy-audit libs/invoice-json
for project in "$@"; do
  mvn --quiet --batch-mode --file "$project/pom.xml" deploy -DaltDeploymentRepository="company::$repo" -Dmaven.install.skip=true
  echo "published $project"
done

from session import run

# network: true (Maven Central). Two teams publish their libraries into the company repository; then the billing
# application, which depends on both, is resolved by Maven, by Maven with its two dependencies in the other order,
# and by Gradle.
run(
    """
sh publish-libs.sh
""",
    show=("java", "maven", "gradle"),
)
run(
    """
mvn -q dependency:tree -Dverbose -DoutputFile=tree.txt
cat tree.txt
mvn -q -f reordered.xml dependency:tree -Dverbose -DoutputFile=tree.txt
cat tree.txt
gradle -q dependencies --configuration runtimeClasspath
""",
    folder="app",
)

# openjdk version "25.0.4.1" LTS · Apache Maven 3.10.0 · Gradle 9.7.1
$ sh publish-libs.sh
published company-parent
published libs/legacy-audit
published libs/invoice-json
$ cd app
$ mvn -q dependency:tree -Dverbose -DoutputFile=tree.txt
$ cat tree.txt
com.example:billing-app:jar:1.0.0
+- com.example:legacy-audit:jar:1.4.0:compile
|  \- com.fasterxml.jackson.core:jackson-databind:jar:2.13.2:compile
|     +- com.fasterxml.jackson.core:jackson-annotations:jar:2.13.2:compile
|     \- com.fasterxml.jackson.core:jackson-core:jar:2.13.2:compile
\- com.example:invoice-json:jar:2.0.0:compile
   \- (com.fasterxml.jackson.core:jackson-databind:jar:2.22.3:compile - omitted for conflict with 2.13.2)
$ mvn -q -f reordered.xml dependency:tree -Dverbose -DoutputFile=tree.txt
$ cat tree.txt
com.example:billing-app:jar:1.0.0
+- com.example:invoice-json:jar:2.0.0:compile
|  \- com.fasterxml.jackson.core:jackson-databind:jar:2.22.3:compile
|     +- com.fasterxml.jackson.core:jackson-annotations:jar:2.22:compile
|     \- com.fasterxml.jackson.core:jackson-core:jar:2.22.3:compile
\- com.example:legacy-audit:jar:1.4.0:compile
   \- (com.fasterxml.jackson.core:jackson-databind:jar:2.13.2:compile - omitted for conflict with 2.22.3)
$ gradle -q dependencies --configuration runtimeClasspath

------------------------------------------------------------
Root project 'billing-app'
------------------------------------------------------------

runtimeClasspath - Runtime classpath of source set 'main'.
+--- com.example:legacy-audit:1.4.0
|    \--- com.fasterxml.jackson.core:jackson-databind:2.13.2 -> 2.22.3
|         +--- com.fasterxml.jackson.core:jackson-annotations:2.22
|         +--- com.fasterxml.jackson.core:jackson-core:2.22.3
|         |    \--- com.fasterxml.jackson:jackson-bom:2.22.3
|         |         +--- com.fasterxml.jackson.core:jackson-annotations:2.22 (c)
|         |         +--- com.fasterxml.jackson.core:jackson-core:2.22.3 (c)
|         |         \--- com.fasterxml.jackson.core:jackson-databind:2.22.3 (c)
|         \--- com.fasterxml.jackson:jackson-bom:2.22.3 (*)
\--- com.example:invoice-json:2.0.0
     \--- com.fasterxml.jackson.core:jackson-databind:2.22.3 (*)

(c) - A dependency constraint, not a dependency. The dependency affected by the constraint occurs elsewhere in the tree.
(*) - Indicates repeated occurrences of a transitive dependency subtree. Gradle expands transitive dependency subtrees only once per project; repeat occurrences only display the root of the subtree, followed by this annotation.

A web-based, searchable dependency report is available by adding the --scan option.

• Maven kept 2.13.2. Its tree marks the other request “omitted for conflict with 2.13.2”. Maven’s dependency guide gives the rule: the nearest definition wins, and when two versions are equally near, the first declaration wins. legacy-audit is declared first.
• Swapping two lines changed the answer. reordered.xml is pom.xml with its two dependencies in the other order, and Maven kept 2.22.3. The order of declarations in a POM is part of what the build produces.
• Gradle kept 2.22.3. Its report shows 2.13.2 -> 2.22.3: Gradle considers every requested version in the graph and, by default, selects the highest. It also applied the constraints that Jackson’s own metadata declares, marked (c), so jackson-core and jackson-annotations moved to the same release.

Neither tool printed a warning. The same declarations gave two different applications, and nothing failed until one of them ran.

Maven and Gradle, side by side

The rows follow each tool’s documentation, cited below. Dependency management in both tools comes down to the same three habits: read the tree, pin the versions you depend on, and make the build fail when something drifts.

The safeguards, by name

• Exact versions. A version such as 2.22.3, never a range, LATEST or RELEASE, so one commit always resolves the same libraries.
• A BOM. A bill of materials is a POM that lists matching versions for a family of modules, such as every Jackson module, imported once.
• Exclusions. An <exclusion> removes one transitive dependency from one path of the tree, so the version that another path brings is the only one left.
• Dependency locking. Gradle writes every resolved version into gradle.lockfile, and later builds keep those versions until someone updates the lock on purpose.
• Checksums and signatures. Maven Central requires a checksum file and a PGP signature beside every file it accepts, and the build tools compare the checksums when they download.
• Pinned hashes. Hashes of every artifact, recorded in your own repository, so that a file replaced on a server fails the build.
• Vulnerability lookups. A scanner looks up each resolved version in an advisory database, such as OSV, and lists the advisories that match.
• Repository filtering. Rules that say which repository may serve which group, so an in-house name is never fetched from a public repository.

Supply-chain safety is these habits applied on every build, by the build itself, rather than remembered by people.

Check yourself

Version conflicts in depth: the failure, four fixes and builds that refuse to guess Pro: opens with a Pro, Premium or Ultimate pass

Reproducible versions: a range that moves, BOMs and lock files, measured Pro: opens with a Pro, Premium or Ultimate pass

Supply-chain drills: a replaced JAR, pinned hashes and known vulnerabilities Pro: opens with a Pro, Premium or Ultimate pass

Key takeaways

• One library can only have one version on a class path: Maven keeps the nearest, then the first declared, and Gradle keeps the highest.
• The order of two dependencies in a POM changed which jackson-databind the application received.
• Read the tree with dependency:tree -Dverbose or gradle dependencies whenever a dependency changes.
• Pin exact versions, keep families together with a BOM, and let the build check checksums and look up advisories.