JIB build breaks for spring-boot if classifier is used

[michael-mader]

Description

I am building an image with jib for a spring-boot application. Spring-boot applications need to be repackaged in a fat jar so that you can run java -jar myApp.jar.

This repackaging can either happen in place or with a classifier. A classifier exec leads to two jars:

• myApp.jar
• myApp-exec.jar

Where myApp-exec.jar is the fat jar.

kubernetes-maven-plugin seems to be able to find correct (fat) jar file but only if run in zero config mode. In this demo repository (a fork of spring-boot-with-jib example from jkube repo) https://github.com/michael-mader/jkube/tree/master/quickstarts/maven/spring-boot-with-jib I have added the repackaging with a classifier.

There are two profiles Jib-Zero-Config and Jib-With-Assembly. Running with the zero config profile selects the correct fat jar and puts it into the container. Running the other profile with some configuration causes the other jar to be included in the container. This jar cannot be run as it is missing the main manifest attribute.

Info

• Eclipse JKube version : 1.6.0
• Maven version (mvn -v) :

  
  Apache Maven 3.8.1 (05c21c65bdfed0f71a2f2ada8b84da59348c4c5d)
  Maven home: /Users/xxx/.sdkman/candidates/maven/current
  Java version: 17.0.1, vendor: Eclipse Adoptium, runtime: /Users/xxx/.sdkman/candidates/java/17.0.1-tem
  Default locale: de_DE, platform encoding: UTF-8
  OS name: "mac os x", version: "11.5", arch: "x86_64", family: "mac"

* Kubernetes / Red Hat OpenShift setup and version : -

* If it's a bug, how to reproduce: 

works as expected

mvn clean package k8s:build -PJib-Zero-Config

does add the wrong jar

mvn clean package k8s:build -PJib-With-Assembly

* Sample Reproducer Project : https://github.com/michael-mader/jkube/tree/master/quickstarts/maven/spring-boot-with-jib

[rohanKanojia]

Does it work when you modify your image configuration to copy the classifier jar also?

When using XML configuration, we should ideally be providing everything via configuration. Looks like this behavior is caused by JKubeProjectUtil.getFinalOutputArtifact copying jar automatically into image. Zero configuration uses FatJarDetector which seems to select correct jar.

        <profile>
            <id>Jib-With-Assembly</id>
            <build>
                <plugins>
                    <plugin>
                        <groupId>org.eclipse.jkube</groupId>
                        <artifactId>kubernetes-maven-plugin</artifactId>
                        <version>${jkube.version}</version>
                        <configuration>
                            <images>
                                <image>
                                    <name>rohankanojia/spring-boot-sample</name>
                                    <build>
                                        <from>fabric8/java-centos-openjdk8-jdk:1.5.6</from>
                                        <assembly>
                                            <inline>
                                                <id>copy-test-file</id>
                                                <files>
                                                    <file>
                                                        <source>
                                                            ${project.basedir}/static/testFile.txt
                                                        </source>
                                                        <outputDirectory>static</outputDirectory>
                                                    </file>
                                                    <file>
                                                        <source>
                                                            ${project.basedir}/target/${project.artifactId}-${project.version}-exec.jar
                                                        </source>
                                                        <outputDirectory>deployments</outputDirectory>
                                                    </file>
                                                </files>
                                            </inline>
                                            <targetDir>/deployments</targetDir>
                                        </assembly>
                                        <cmd>java -jar /deployments/${project.artifactId}-${project.version}-exec.jar</cmd>
                                        <ports>
                                          <port>8080</port>
                                        </ports>
                                    </build>
                                </image>
                            </images>
                        </configuration>
                    </plugin>
                </plugins>
            </build>
        </profile>

[manusa]

With a manual assembly configuration, you are responsible of including the files that you want.

Looks like this behavior is caused by JKubeProjectUtil.getFinalOutputArtifact

By the default, the assembly will include what Maven has set as the main artifact for the project.

In you current scenario, you don't want that file, so in addition to what Rohan pointed out, you should also add the <excludeFinalOutputArtifact>true</excludeFinalOutputArtifact> option to your <assembly> configuration.

[michael-mader]

Does it work when you modify your image configuration to copy the classifier jar also?

When using XML configuration, we should ideally be providing everything via configuration. Looks like this behavior is caused by JKubeProjectUtil.getFinalOutputArtifact copying jar automatically into image. Zero configuration uses FatJarDetector which seems to select correct jar.

        <profile>
            <id>Jib-With-Assembly</id>
            <build>
                <plugins>
                    <plugin>
                        <groupId>org.eclipse.jkube</groupId>
                        <artifactId>kubernetes-maven-plugin</artifactId>
                        <version>${jkube.version}</version>
                        <configuration>
                            <images>
                                <image>
                                    <name>rohankanojia/spring-boot-sample</name>
                                    <build>
                                        <from>fabric8/java-centos-openjdk8-jdk:1.5.6</from>
                                        <assembly>
                                            <inline>
                                                <id>copy-test-file</id>
                                                <files>
                                                    <file>
                                                        <source>
                                                            ${project.basedir}/static/testFile.txt
                                                        </source>
                                                        <outputDirectory>static</outputDirectory>
                                                    </file>
                                                    <file>
                                                        <source>
                                                            ${project.basedir}/target/${project.artifactId}-${project.version}-exec.jar
                                                        </source>
                                                        <outputDirectory>deployments</outputDirectory>
                                                    </file>
                                                </files>
                                            </inline>
                                            <targetDir>/deployments</targetDir>
                                        </assembly>
                                        <cmd>java -jar /deployments/${project.artifactId}-${project.version}-exec.jar</cmd>
                                        <ports>
                                          <port>8080</port>
                                        </ports>
                                    </build>
                                </image>
                            </images>
                        </configuration>
                    </plugin>
                </plugins>
            </build>
        </profile>

ok thanks for your answer. I'll check if it is working like you suggested. But I still don't understand, why the spring-boot generator is not used in this scenario? My understanding was, that you can add explicit configuration on top, but it seems like you are replacing everything when setting a configuration.

Edit: Thank you! It is working with your and @manusa proposed changes. @manusa This seems to be not (only) caused by <assembly> as I did not have any assembly Tags in my project before. Setting <configuration> seems to be enough for the default mechanisms to "fail"

[manusa]

Generators are meant to provide an opinionated image configuration for your project. They are a zero-config alternative to <configuration><images><image>.

The fact that you provide an image configuration for your project, in most cases will disable the zero-config generators.

seems to be enough for the default mechanisms to "fail"

This shouldn't be the case. However, setting <configuration><images><image> in most cases does (due to the mentioned reasons).

My understanding was, that you can add explicit configuration on top, but it seems like you are replacing everything when setting a configuration

You can add configuration on top, but configuration which is not mutually exclusive such as a manually configured image.

e.g. for the Spring Boot generator you can set most of the java-exec options, plus color customization.

I see this confusion on many users, but we can't really find a proper way to explain this better.

In a nutshell, JKube provides three ways to generate Container Images:

• Zero Config via generators: You don't need to provide any configuration, JKube detects everything for you. You can fine-tune some of the options which are specific for each generator.
• XML/DSL configuration: You provide a manually configured image via pom.xml or build.gradle configuration
• Dockerfile: You provide an image configuration via a standard Dockerfile. Further options (such as context, etc.) can be customized via XML or DSL.

[michael-mader]

thanks for making this clear!