Gradle platform or Maven BOM: how do you share dependency versions?

Use a Maven BOM imported into dependencyManagement, or a Gradle platform declared with the platform keyword, to keep related library versions aligned across modules. Gradle can consume published Maven BOMs and publish its own platforms as BOMs, so mixed shops can share one source of version truth.

What each one is

A Maven BOM is a POM with packaging pom whose dependencyManagement section lists versions. Other projects import it. The Maven guide describes the pattern for keeping project versions in sync with a library's distributed versions.

A Gradle platform is a component made of dependency constraints. Gradle's documentation says platforms are useful for sharing consistent versions across multiple projects. Local platforms are created with the java-platform plugin, and published ones can be Maven BOMs, such as a testing library's BOM.

Side by side

The Gradle documentation says using the platform notation sets the platform category attribute and enables the endorseStrictVersions behavior by default, which enforces strict versions defined in the platform.

Example of consuming a BOM in Gradle

dependencies {
    implementation(platform("org.junit:junit-bom:5.10.0"))
    testImplementation("org.junit.jupiter:junit-jupiter")
}

The second line has no version, because the platform supplies it.

Using one for security patches

A shared platform gives you one file where a security fix lands once and every module gets it:

1. Create a platform project that holds constraints for libraries you have had to patch.
2. Make every module depend on it.
3. When an advisory lands, bump the version in the platform only.
4. Rebuild all modules and compare SBOMs before and after to see what changed.
5. Delete a constraint when upstream catches up so the platform does not become a graveyard of old pins.

This beats scattering overrides across fifty build files, where one gets missed. For the transitive mechanics, see how to force a patched transitive dependency in Gradle and why Maven picks an old version.

Watch for these

Constraints in a platform are only fully preserved when consumers use Gradle Module Metadata, per the documentation. If you publish a platform to Maven users, a BOM is the safer form. And do not confuse either with an SBOM, which records what shipped. Our post on BOM versus SBOM covers that.

A rule of thumb

Pick whichever matches your build tool, and generate the other artifact only when you have downstream users on it. Mixed Gradle and Maven estates benefit most from one published BOM that both can read.

Safeguard dependency scanning and SBOMs show what each module actually resolved, including versions your platform controls, so you can confirm a patch took effect. Free scan: gold.safeguard.sh/scan.

Quick check

Sources

• Platforms, Gradle documentation
• Dependency Constraints, Gradle documentation
• Introduction to the Dependency Mechanism, Apache Maven

Last reviewed: 19 October 2026.