All 15 Build Tools: Maven & Gradle questions
More in Build Tools: Maven & Gradle
What is the Maven build lifecycle, and what do the common phases (validate, compile, test, package, install, deploy) each do? How does Gradle's build script (build.gradle / build.gradle.kts) differ structurally from Maven's declarative XML pom.xml? What is the difference between Maven's <dependencies> scope values (compile, provided, runtime, test) and how do they affect what's included in the final packaged artifact? How do you resolve a dependency version conflict manually in Maven using exclusions, and when would this be necessary despite the automatic nearest-wins resolution? How do you manage different configurations for different environments (development, staging, production) using Maven profiles or Gradle's equivalent mechanisms? How do you configure the Maven Compiler Plugin to target a specific Java language version, and what's the difference between source, target, and release configuration? How does Maven's dependency resolution algorithm handle transitive dependency version conflicts, and what is the "nearest definition wins" rule? How does Gradle's incremental build and build cache mechanism achieve significantly faster rebuild times compared to Maven's default behavior? How would you configure a multi-module Maven or Gradle project, and what benefits does modularizing a large codebase this way provide? How would you write a custom Maven plugin or Gradle task to perform project-specific build automation not covered by existing plugins?
Advertisement
Java › Build Tools: Maven & Gradle

What is a Maven BOM (Bill of Materials), and how does it help manage consistent dependency versions across a multi-module project or organization?

Intermediate

Answer

A BOM is a special pom.xml (packaging type "pom") that declares a curated, consistent set of dependency versions inside <dependencyManagement> without actually including those dependencies itself -- importing a BOM via <scope>import</scope> lets your project's own dependency declarations omit explicit version numbers entirely (inheriting the BOM's version), ensuring all dependencies from a related family (like Spring Boot's own BOM covering dozens of compatible Spring ecosystem libraries) stay mutually compatible without manually tracking each version yourself.
<dependencyManagement>
    <dependencies>
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-dependencies</artifactId>
            <version>3.2.0</version>
            <type>pom</type>
            <scope>import</scope>
        </dependency>
    </dependencies>
</dependencyManagement>

<!-- No version needed -- inherited from the imported BOM -->
<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-web</artifactId>
</dependency>
Real-world example A Spring Boot project imports the spring-boot-dependencies BOM, letting every Spring-related dependency declaration across the entire project omit explicit version numbers, guaranteeing all the interdependent Spring modules stay on mutually-tested, compatible versions as a cohesive set rather than needing manual version coordination.

Common follow-ups: How would an organization create and publish its own internal BOM to standardize dependency versions across many internal projects?;What's Gradle's equivalent mechanism for importing a BOM (the platform() function)?

Configuration & Options Pattern;Deploy Checklist
All 15 Build Tools: Maven & Gradle questions