Create a Fat Jar App with Spring Boot

Refactor Java code safely — and automatically — with OpenRewrite.

Refactoring big codebases by hand is slow, risky, and easy to put off. That’s where OpenRewrite comes in. The open-source framework for large-scale, automated code transformations helps teams modernize safely and consistently.

Each month, the creators and maintainers of OpenRewrite at Moderne run live, hands-on training sessions — one for newcomers and one for experienced users. You’ll see how recipes work, how to apply them across projects, and how to modernize code with confidence.

Join the next session, bring your questions, and learn how to automate the kind of work that usually eats your sprint time.

Distributed systems often come with complex challenges such as service-to-service communication, state management, asynchronous messaging, security, and more.

Dapr (Distributed Application Runtime) provides a set of APIs and building blocks to address these challenges, abstracting away infrastructure so we can focus on business logic.

In this tutorial, we'll focus on Dapr's pub/sub API for message brokering. Using its Spring Boot integration, we'll simplify the creation of a loosely coupled, portable, and easily testable pub/sub messaging system:

>> Flexible Pub/Sub Messaging With Spring Boot and Dapr

1. Introduction

One of the more heart-warming developments of recent years has been an ongoing simplification of how web applications are deployed.

Skipping all the boring intermediate historical steps, we arrive at today – when we can dispense with not only cumbersome servlets and XML boilerplate, but mostly the servers themselves.

This article will concentrate on creating a “fat jar” out of a Spring Boot application – basically to create a single artifact that is easy to deploy and run.

Boot provides capabilities for container-less deployments right out of the box: all we need to do is to add a couple of configurations in the pom.xml:

<dependencies>
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-web</artifactId>
    </dependency>
</dependencies>

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

2. Build and Run

With this configuration, we can now simply build the project with the standard mvn clean install – nothing unusual here.

And we run it with the following command: java -jar <artifact-name> – very simple and intuitive.

Proper process management is beyond the scope of this article, but one simple way to keep the process running even when we logoff the server is to use the nohup command: nohup java -jar <artifact-name>.

Stopping spring-boot projects is also no different than stopping a regular process, whether we simply cntrl+c or kill <pid>.

3. Fat Jar / Fat War

Behind the scenes, spring-boot packages all the project dependencies inside the final artifact along side project classes (hence the “fat” jar). An embedded Tomcat server is also built-in.

And thus, the resulting artifact is completely self-contained, easy to deploy using standard Unix tools (scp, sftp…etc) and can be run on any server with a JVM.

By default, Boot creates a jar file – but if we change the packaging property in pom.xml to war, Maven will instead naturally build a war.

This will of course be both executable as stand-alone, and deployed to a web container.

4. Further Config

Most of the time no additional configuration is needed, everything “just works”, but in some specific cases, we may need to tell spring-boot explicitly what the main class is. One way to do it would be to add a property:

<properties>
    <start-class>org.baeldung.boot.Application</start-class>
</properties>

In case we’re not inheriting spring-boot-starter-parent we’ll need to do it in the Maven plugin:

<plugin>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-maven-plugin</artifactId>
    <version>2.4.0</version>
    <configuration>
        <mainClass>org.baeldung.boot.Application</mainClass>
        <layout>ZIP</layout>
    </configuration>
</plugin>

Another thing we might need to do in some rare cases is to instruct Maven to unpack some dependencies:

<plugin>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-maven-plugin</artifactId>
    <configuration>
        <requiresUnpack>
            <dependency>
                <groupId>org.jruby</groupId>
                <artifactId>jruby-complete</artifactId>
            </dependency>
        </requiresUnpack>
    </configuration>
</plugin>