Learn Spring Boot - Modern Tooling & Build Automation

#Introduction

The build tool is the silent assistant running your entire development pipeline. Choosing and understanding this tool correctly makes the team more productive and artifacts more reliable. Episode 19 covers modern tooling and build automation.

You'll compare Maven and Gradle, understand the Spring Boot plugin and BOM dependency management, speed up iteration with Spring DevTools, and build multi-module projects with reproducible builds.

#Maven vs Gradle Kotlin DSL

#Maven: Simple and Standard

Maven uses XML-based pom.xml with a clear lifecycle — clean, compile, test, package, install. Its strengths: consistent, well documented, and the default for Spring Initializr. The Maven project structure hasn't changed much in a long time.

<build>
    <plugins>
        <plugin>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-maven-plugin</artifactId>
        </plugin>
    </plugins>
</build>

The spring-boot-maven-plugin produces an executable jar — the key to ./mvnw spring-boot:run and java -jar.

#Gradle with Kotlin DSL

Gradle uses scripts — build.gradle.kts with Kotlin DSL — which are more expressive and flexible. Its build cache and incremental builds are very fast for large projects:

plugins {
    id("org.springframework.boot") version "3.4.1"
    id("io.spring.dependency-management") version "1.1.7"
    java
}
 
group = "com.example"
version = "0.0.1-SNAPSHOT"
 
repositories { mavenCentral() }
 
dependencies {
    implementation("org.springframework.boot:spring-boot-starter-web")
    testImplementation("org.springframework.boot:spring-boot-starter-test")
}

Notice: dependency versions don't need to be written manually. The io.spring.dependency-management plugin applies the Spring Boot BOM so all library versions are agreed upon automatically.

#The Spring Boot Plugin and BOM Dependency Management

#What Is a BOM

A BOM (Bill of Materials) is a file that declares the versions of all Spring libraries in one place. Spring Boot publishes a BOM for each release — for example spring-boot-dependencies:3.4.1. When you upgrade the Spring Boot version, all library versions stay coordinated.

In Maven, the BOM is imported through dependency management:

<parent>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-parent</artifactId>
    <version>3.4.1</version>
</parent>

This starter parent imports the Spring Boot BOM and provides default plugin configuration. That's why you don't need to write version numbers for starter dependencies — version consistency is guaranteed by the BOM.

#Using the Plugin for Packaging

The Spring Boot plugin also offers additional goals: spring-boot:run to run the application, spring-boot:repackage to create an executable jar, and spring-boot:build-image to build an OCI image. Here's an example building a container image directly from Maven:

./mvnw spring-boot:build-image -Dspring-boot.build-image.imageName=belajar:1.0

The command ./mvnw spring-boot:build-image -Dspring-boot.build-image.imageName=belajar:1.0 produces a container image with a buildpack — without writing a Dockerfile. We'll also use this approach in episode 20.

#Live Reload with Spring DevTools

#The DevTools Dependency

Spring DevTools speeds up the development loop. Add the dependency:

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-devtools</artifactId>
    <scope>runtime</scope>
</dependency>

DevTools provides automatic restart when classes change: the application restarts with a new classloader without a full JVM restart — much faster. Changes to application.yml are also applied immediately. Make sure this dependency doesn't ship to production — the runtime scope and packaging scripts handle that.

#Other DevTools Features

• LiveReload — the browser refreshes automatically when static resources change.
• Development default properties — template caching is off, error pages show more detail.
• Global configuration — a development profile that activates automatically when running the application from the IDE.

These features make the write-change-test loop much faster. In CI/CD, make sure DevTools doesn't slow down the build.

#Reproducible Builds and Multi-Module Projects

#Reproducible Builds

A reproducible build produces identical artifacts every time it's built from the same source — important for trust and supply chain auditing. A few steps in Maven:

project.build.outputTimestamp=2026-08-10T00:00:00Z

Setting outputTimestamp removes the changing timestamps from the jar, making the artifact deterministic. Verify by running ./mvnw verify twice and comparing the checksums of the artifacts.

#Multi-Module Projects

For large applications, split the project into modules. In Maven, declare the modules in the root pom.xml:

<modules>
    <module>domain</module>
    <module>application</module>
    <module>infrastructure</module>
    <module>web</module>
</modules>

This structure lets each module compile and test independently, while the root project builds everything in sequence. Multi-module is the practical foundation of the modular architecture discussed in episode 18.

#Closing

Episode 19 equipped you with modern tooling: a comparison of Maven and Gradle Kotlin DSL, the role of the Spring Boot plugin and BOM in dependency management, faster development with Spring DevTools, and reproducible builds and multi-module projects.

Key takeaways:

• Maven is consistent and standard; Gradle is flexible and fast for large projects.
• The Spring Boot BOM unifies all library versions in one place.
• spring-boot-maven-plugin produces executable jars and container images.
• Spring DevTools enables automatic restart and live reload in development.
• project.build.outputTimestamp makes builds reproducible.
• Multi-module projects break large codebases into manageable units.

In the next episode, episode 20, we'll discuss cloud-native deployment — optimizing the Dockerfile with multi-stage builds, Spring Boot Native Image with GraalVM and AOT, Kubernetes integration with readiness probes, and deployment to AWS, GCP, Azure, and PaaS platforms.