Since some libraries contain licenses that do not allow distribution, customers who want to run our software must get the libraries by themselves and add these to the spring boot application.
Previously, we added the spring boot uber jar to a container and used the PropertiesLauncher
and the LOADER_PATH
so that the customer can mount the library in the container and adapt the classpath.
Now that we want to switch for the image generation to buildpack, just like mvn spring-boot:build-image
would do. As the application is unpacked in the image, it seems to me that the PropertiesLauncher
and LOADER_PATH
would no longer work.
What is the recommended way to add third party Java libraries to a buildback-built spring boot container?
Turns out the configuration of the spring-boot-maven-plugin
was wrong. The configuration <layout>ZIP<layout>
was only active for the repackage
goal, but not for the build-image
goal.
After correctly configuring <layout>ZIP<layout>
for the build-image
goal, the generated buildpack-image uses the org.springframework.boot.loader.launch.PropertiesLauncher
which allows again the use of the LOADER_PATH
.
To clarify, this was my wrong configuration:
<plugin>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-maven-plugin</artifactId>
<version>${version.spring-boot}</version>
<executions>
<execution>
<goals>
<goal>build-info</goal>
<goal>repackage</goal>
</goals>
<configuration>
<layout>ZIP</layout>
<classifier>app</classifier>
</configuration>
</execution>
</executions>
</plugin>
The fixed configuration, where the layout (and also the classifier) is always present regardless of the actual spring-boot-maven-plugin goal:
<plugin>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-maven-plugin</artifactId>
<version>${version.spring-boot}</version>
<configuration>
<layout>ZIP</layout>
<classifier>app</classifier>
</configuration>
<executions>
<execution>
<goals>
<goal>build-info</goal>
<goal>repackage</goal>
</goals>
</execution>
</executions>
</plugin>