spring-boot:build-image hangs on multi-module project

[ch4mpy]

Running mvn spring-boot:build-image at the root of a multi-module maven project hangs forever.

Sample project there: [email protected]:ch4mpy/lifix.git

Last logs output:

[INFO] --- spring-boot-maven-plugin:2.5.3:build-image (default-cli) @ common-storage ---
[INFO] Building image 'docker.io/library/common-storage:0.0.1-SNAPSHOT'
[INFO]
[INFO]  > Pulling builder image 'docker.io/paketobuildpacks/builder:base' 100%
[INFO]  > Pulled builder image 'paketobuildpacks/builder@sha256:4fae5e2abab118ca9a37bf94ab42aa17fef7c306296b0364f5a0e176702ab5cb'
[INFO]  > Pulling run image 'docker.io/paketobuildpacks/run:base-cnb' 100%
[INFO]  > Pulled run image 'paketobuildpacks/run@sha256:a285e73bc3697bc58c228b22938bc81e9b11700e087fd9d44da5f42f14861812'
[INFO]  > Executing lifecycle version v0.11.4
[INFO]  > Using build cache volume 'pack-cache-382e7345203f.build'
[INFO]
[INFO]  > Running creator

and then nothing for more than 1/2 hour.

I Also tried to run

• mvn package -Pnative
• mvn clean install and then mvn spring-boot:build-image -pl faults-endpoints (where faults-endpoints is a spring-boot app for which I'd like to have a native image).

Both of the later fail, but with following error message, which make me think it's a distinct issue:

[INFO]     [creator]     Error: Error parsing dynamic proxy configuration in file:/workspace/META-INF/native-image/org.springframework.aot/spring-aot/proxy-config.json:
[INFO]     [creator]     java.lang.IllegalArgumentException: repeated interface: org.springframework.aop.SpringProxy
[INFO]     [creator]     Verify that the configuration matches the schema described in the -H:PrintFlags=+ output for option DynamicProxyConfigurationResources.
[INFO]     [creator]     Error: Use -H:+ReportExceptionStackTraces to print stacktrace of underlying exception
[INFO]     [creator]     Error: Image build request failed with exit status 1
[INFO]     [creator]     unable to invoke layer creator
[INFO]     [creator]     unable to contribute native-image layer
[INFO]     [creator]     error running build
[INFO]     [creator]     exit status 1
[INFO]     [creator]     ERROR: failed to build: exit status 1

My point here is: shouldn't mvn spring-boot:build-image at root of multi-module project ignore non-application modules ? (or at least exit with error message)

[sdeleuze]

If the build hang with Buildpacks, that's probably because there is not enough memory for Docker, see this section for guidance.

You can also see a sample multi-module project in https://github.com/spring-projects-experimental/spring-native/tree/main/samples/multi-modules to compare.

[ch4mpy]

@sdeleuze have you tried to cd spring-native\samples\multi-modules && mvn spring-boot:build-image?

Because I face the same problem (hangs on [INFO] > Running creator)

mvn spring-boot:build-image -pl app also hangs, but after successfully building the image.

Docker is running with WSL2 based engine and here is my .wslconfig:

[wsl2]
memory=24GB
processors=8

[scottfrederick]

I can re-create the hanging with cd spring-native\samples\multi-modules && mvn spring-boot:build-image. At first glance, this would appear to be related to a few other issues we've had with the Spring Boot Maven plugin (see spring-projects/spring-boot#25590 and spring-projects/spring-boot#25736). I'll see if I can get to the root of the hanging.

shouldn't mvn spring-boot:build-image at root of multi-module project ignore non-application modules?

When running the spring-boot:build-image goal directly, Maven doesn't know how to treat distinct modules in a multi-module project. The README for the multi-modules sample says to run mvn package -Pnative instead, because the app module of the project is configured to attach build-image to the package phase while the core module does not configure build-image. Running mvn package -Pnative from the root works for me. @ch4mpy you should be able to configure your multi-module project similarly to work around the issue.

BTW @sdeleuze the multi-modules sample is out-of-date, using spring-boot-starter-parent version 2.4.3 and spring-native.version 0.9.1. Upgrading to Spring Boot 2.5.3 and Spring Native 0.10.2-SNAPSHOT doesn't have any affect on this issue though.

[ch4mpy]

The README for the multi-modules sample says to run mvn package -Pnative instead.

Yes it does. But https://docs.spring.io/spring-native/docs/current/reference/htmlsingle/ doesn't and path to finding this specific multi-module sample is rather tricky.

if mvn package with a simple native profile is a more universal way to package native apps, shouldn't main documentation point in that direction instead ?

I feel like mono-repos, and as so multi-module, are quite frequent nowadays for projects that are not just PoC...

[scottfrederick]

@ch4mpy I've acknowledged that there could be a problem in Spring Boot Maven plugin that's causing the hanging. It's possible that some documentation improvements could be made in the Spring Boot and/or Spring Native projects to cover a use case like this also. My comment about using a technique similar to what was done in the sample was only intended to give you an option to move forward as the teams continue to investigate and think about the problem.

[scottfrederick]

I've confirmed that the Maven plugin hanging while creating an image is a problem in Spring Boot, and opened an issue to address that.

shouldn't mvn spring-boot:build-image at root of multi-module project ignore non-application modules ? (or at least exit with error message)

If you run any goal at the root of a multi-module project, Maven will execute the goal on every module. The spring-boot:build-image goal should not try to guess which module(s) are applications and which are libraries and apply itself selectively. In this scenario, you'll need to configure the build to attach the build-image goal to a phase in the modules that should be used to generate an image, and not attach the goal in library modules.

Once the Spring Boot issue is resolved, you'll get appropriate feedback when running build-image on all modules in a project.

[ch4mpy]

@scottfrederick my feature request was messy (and wrong), sorry.

Could we consider build-image as a sort of repackage?

Ideally, I'd like to be able to run mvn package and get "fat-jars" for all modules with spring-boot-maven-plugin and also native image for those having both spring-boot-maven-plugin and spring-aot-maven-plugin

This means having spring-boot:build-image behave quite the same as spring-boot:repackage: hook on package target, just require an additional plugin to activate

[sdeleuze]

Thanks @scottfrederick, I am closing this issue on Spring Native side since you have created one on Spring Boot side.

[scottfrederick]

Could we consider build-image as a sort of repackage?

@ch4mpy The repackage and build-image goals are configured in very much the same way. Both bind to the package phase by default, and the Spring Boot plugin must be activate for either to do anything. The only real difference is that repackage is activated by default when using spring-boot-starter-parent as a Maven parent project (as mentioned in the documentation), but build-image is not activated by default.

Ideally, I'd like to be able to run mvn package and get "fat-jars" for all modules with spring-boot-maven-plugin and also native image for those having both spring-boot-maven-plugin and spring-aot-maven-plugin

This means having spring-boot:build-image behave quite the same as spring-boot:repackage: hook on package target, just require an additional plugin to activate

You can get the outcome you're describing by configuring your build as suggested above. Add spring-boot-maven-plugin to all modules so they get repackaged, and only add the build-image execution in modules that you want an OCI image for. You'll need to do the appropriate configuration of spring-boot-maven-plugin in each module to make that work. The spring-boot-maven-plugin and spring-aot-maven-plugin do not and should not know about each other as they serve different purposes, so one plugin won't influence the behavior of the other.