Optimizing Spring Boot Fat JARs: Splitting Dependencies and Reducing Deployment Size

Overview

Spring Boot makes it easy to build a single executable JAR, but as projects grow the JAR can reach hundreds of megabytes. Deploying such large files for each micro‑service or for frequent bug‑fix releases becomes time‑consuming.

This guide shows how to break a fat JAR into a small business JAR plus a lib directory that holds all third‑party dependencies, dramatically reducing the size of the artifact that needs to be transferred.

Level 0 – Conventional Fat JAR

Typical Maven configuration using spring-boot-maven-plugin produces a single large JAR. Example build snippet:

<build>
    <finalName>${project.artifactId}</finalName>
    <plugins>
        <plugin>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-maven-plugin</artifactId>
        </plugin>
    </plugins>
</build>

Running mvn clean install yields a JAR of ~16 MB (in the demo) but real projects often exceed 100 MB.

Level 1 – Separate Dependencies into lib

Use maven-dependency-plugin to copy all compile‑time dependencies into target/lib and configure the Spring Boot plugin to exclude them from the executable JAR.

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-dependency-plugin</artifactId>
    <executions>
        <execution>
            <id>copy-dependencies</id>
            <phase>package</phase>
            <goals><goal>copy-dependencies</goal></goals>
            <configuration>
                <outputDirectory>${project.build.directory}/lib</outputDirectory>
                <excludeTransitive>false</excludeTransitive>
                <stripVersion>false</stripVersion>
                <silent>true</silent>
            </configuration>
        </execution>
    </executions>
</plugin>

<plugin>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-maven-plugin</artifactId>
    <configuration>
        <includes>
            <!-- exclude all normal dependencies -->
            <include>null</include>
        </includes>
        <layout>ZIP</layout>
    </configuration>
</plugin>

The resulting business JAR is only ~150 KB; the lib directory holds the external jars. Deployment now requires transferring a tiny JAR plus the shared lib once.

Level 2 – Shared lib for Multiple Services

When many micro‑services share most dependencies, copy all dependencies of every module into a single common lib directory and let each service’s JAR reference that directory via the manifest Class-Path entry.

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-jar-plugin</artifactId>
    <configuration>
        <archive>
            <manifest>
                <addClasspath>true</addClasspath>
                <classpathPrefix>lib/</classpathPrefix>
                <useUniqueVersions>false</useUniqueVersions>
            </manifest>
        </archive>
    </configuration>
</plugin>

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-dependency-plugin</artifactId>
    <executions>
        <execution>
            <id>copy-dependencies</id>
            <phase>package</phase>
            <goals><goal>copy-dependencies</goal></goals>
            <configuration>
                <outputDirectory>${boot-jar-output}/lib</outputDirectory>
                <excludeTransitive>false</excludeTransitive>
                <stripVersion>false</stripVersion>
                <silent>false</silent>
            </configuration>
        </execution>
    </executions>
</plugin>

All services now share a common lib of ~200 MB, while each service JAR stays under 200 KB, enabling fast incremental updates.

Level 3 – Handling System‑Scope Third‑Party SDKs

Some SDKs are added with system scope and are not automatically included in the manifest. By adding a custom Class-Path entry via manifestEntries, those jars can be referenced as well.

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-jar-plugin</artifactId>
    <configuration>
        <archive>
            <manifest>
                <addClasspath>true</addClasspath>
                <classpathPrefix>lib/</classpathPrefix>
                <useUniqueVersions>false</useUniqueVersions>
            </manifest>
            <manifestEntries>
                <Class-Path>${jar-manifestEntries-classpath}</Class-Path>
            </manifestEntries>
        </archive>
    </configuration>
</plugin>

<properties>
    <jar-manifestEntries-classpath>. lib/hik-sdk-1.0.0.jar</jar-manifestEntries-classpath>
</properties>

<dependency>
    <groupId>com.hik</groupId>
    <artifactId>hik-sdk</artifactId>
    <version>1.0.0</version>
    <scope>system</scope>
    <systemPath>${project.basedir}/lib/hik-sdk-1.0.0.jar</systemPath>
</dependency>

The resulting manifest contains both the shared dependencies and the SDK path, ensuring the application can locate all required classes at runtime.

Final Result

All services share a common lib directory (≈200 MB total).

Each service JAR is reduced to 150‑200 KB, allowing near‑instant updates.

Manifest Class-Path entries lock each service to specific dependency versions, preventing version conflicts.

System‑scope third‑party SDKs are also supported via custom manifest entries.

Additional Tips

When a Maven dependency version changes, remember to update the shared lib directory accordingly. Storing the deployment resources in a Git repository makes it easy to track which files have changed between releases, minimizing the amount of data that needs to be transferred.