java/spring-boot/gradle Wrong Entrypoint in image built with pack and paketobuildpacks/builder:base-CodePudding

I have a really simple java spring-boot gradle application. When I build an image from source with:

pack build testapp:0.0.1 --builder paketobuildpacks/builder:base

and try to run it with docker I get the following error:

ERROR: failed to launch: determine start command: when there is no default process a command is required.

The generated Entrypoint in this image is "/cnb/lifecycle/launcher".

When I inspect the image with pack inspect-image there are no processes.

I tried this with different java spring-boot gradle applications. When I use the "bootBuildImage" gradle task, it does nearly the same but uses the pre-build .jar-file and the resulting image works. The generated Entrypoint in this image is "/cnb/process/web" and pack inspect-image shows three processes.

Any ideas?

CodePudding user response：

I can't see your build output, but it sounds like you're hitting a known issue. If this is not your problem, please include the full output of running pack build.

Onto the issue. By default, Spring Boot Gradle projects will build both an executable and non-executable JAR. Because this produces two JAR files, it presently confuses the buildpacks.

There are a couple of solutions:

Tell Gradle to not build the non-executable JAR. The buildpack requires the executable JAR. You can do this by adding the following to your build.gradle file:
```
jar {
    enabled = false
}
```
This is the solution we have used in the Paketo buildpack samples.
If you don't want to make the change suggested in #1, then you can add the following argument to pack build: -e BP_GRADLE_BUILT_ARTIFACT=build/libs/<your-jar>.jar. For ex: -e BP_GRADLE_BUILT_ARTIFACT=build/libs/demo-0.0.1-SNAPSHOT.jar. You can use glob-style pattern matching here, but you need to make sure that what you enter does not match *-plain.jar. That will be the non-executable JAR that gets built by default.

This option just simply tells the Gradle buildpack more specifically what the JAR file to pass along to subsequent buildpacks.

We also have an open issue that should help to mitigate this problem. When the executable-jar buildpack gains support for multiple JARs, it'll be less likely that you'll need to set this. Essentially, this fill will add support so the executable-jar buildpack can inspect and detect an executable JAR, which would allow it to throw out the -plain.jar file since it's not executable.