Custom Spring Boot Packaging: Using spring-boot-maven-plugin and maven-assembly-plugin to Separate Dependencies

Spring Boot normally produces a fat jar that contains all dependencies and can be started with java -jar xxx.jar . The author’s company moves the dependency jars to an external libs directory and starts the application with java -Dloader.path=libs -jar xxxx.jar .

This approach makes it easy to replace a single problematic dependency without rebuilding the whole jar.

The packaging is achieved with two Maven plugins: spring-boot-maven-plugin and maven-assembly-plugin .

spring-boot-maven-plugin is the official Spring Boot plugin that creates a fat jar and supports the java -jar xxx.jar launch command. To avoid bundling dependencies, the plugin is configured with layout=ZIP and an includes entry that references a non‑existent jar, effectively excluding all libraries.

maven-assembly-plugin provides flexible content customization. In assembly.xml the include and exclude patterns (using regular expressions) are used to extract only the required dependencies into the libs directory. Running mvn clean package generates an installation package in the target folder.

After unpacking the generated package, the libs directory contains the external dependency jars.

For startup, Spring Boot’s launcher class org.springframework.boot.loader.Launcher is used. With the layout=ZIP setting, the PropertiesLauncher subclass is selected. The launcher reads loader.path (or the LOADER_PATH environment variable) to add additional classpath locations, e.g., lib,${HOME}/app/lib . The application can therefore be started with a command such as java -jar -Dloader.path=xx1,xx2,public <jarName>.jar , which loads all jars in the specified directories.

The PropertiesLauncher by default loads jars from BOOT-INF/lib/ . By providing a loader.properties file or setting the environment variable, you can override this behavior and point to any directory containing the needed libraries.

In summary, although this packaging and launch method is not common, it is valuable for projects with many component modules, allowing urgent fixes to be applied by swapping individual jars and limiting the impact of changes.