How to force mvn -Dnative to select a later version of Paketo Buildpack for JDK 21 builds

jfslin commented 3 months ago

Describe the bug

I am trying to build using ./mvnw clean install -Dnative "-Dquarkus.container-image.build=true" "-Dquarkus.native.container-build=true" "-Dquarkus.buildpack.builder-env.BP_JVM_VERSION=21" which triggers the build against the following libraries:

===> DETECTING
10 of 26 buildpacks participating
paketo-buildpacks/ca-certificates   3.6.3
paketo-buildpacks/bellsoft-liberica 10.2.6
paketo-buildpacks/syft              1.32.1
paketo-buildpacks/maven             6.15.5
paketo-buildpacks/executable-jar    6.7.4
paketo-buildpacks/apache-tomcat     7.13.7
paketo-buildpacks/apache-tomee      1.7.4
paketo-buildpacks/liberty           3.8.2
paketo-buildpacks/dist-zip          5.6.4
paketo-buildpacks/spring-boot       5.26.1

It crashes as the version of Paketo Buildpack that it uses doesn't support JDK 21:

Paketo Buildpack for BellSoft Liberica 10.2.6
  unable to find dependency
  no valid dependencies for jdk, 21, and io.buildpacks.stacks.bionic in [(jdk, 8.0.372, [io.buildpacks.stacks.bionic io.paketo.stacks.tiny *]) (jre, 8.0.372, [io.buildpacks.stacks.bionic io.paketo.stacks.tiny *]) (jdk, 11.0.19, [io.buildpacks.stacks.bionic io.paketo.stacks.tiny *]) (jre, 11.0.19, [io.buildpacks.stacks.bionic io.paketo.stacks.tiny *]) (native-image-svm, 11.0.19, [io.buildpacks.stacks.bionic io.paketo.stacks.tiny *]) (jdk, 17.0.7, [io.buildpacks.stacks.bionic io.paketo.stacks.tiny *]) (jre, 17.0.7, [io.buildpacks.stacks.bionic io.paketo.stacks.tiny *]) (native-image-svm, 17.0.7, [io.buildpacks.stacks.bionic io.paketo.stacks.tiny *]) (jdk, 20.0.1, [io.buildpacks.stacks.bionic io.paketo.stacks.tiny *]) (jre, 20.0.1, [io.buildpacks.stacks.bionic io.paketo.stacks.tiny *])]

Looking at the current version of this package, 10.8.2, does indeed support JDK 21: https://github.com/paketo-buildpacks/bellsoft-liberica/releases/tag/v10.8.2

However, I can't seem to figure out how to get maven to select a newer version of this library. Trying graalvm or the latest version of Mandrel both yields the same result:

./mvnw clean install -Dnative "-Dquarkus.container-image.build=true" "-Dquarkus.native.container-build=true" "-Dquarkus.buildpack.builder-env.BP_JVM_VERSION=21" "-Dquarkus.native.builder-image=quay.io/quarkus/ubi-quarkus-mandrel-builder-image:jdk-22"
./mvnw clean install -Dnative "-Dquarkus.container-image.build=true" "-Dquarkus.native.container-build=true" "-Dquarkus.buildpack.builder-env.BP_JVM_VERSION=21" "-Dquarkus.native.builder-image=graalvm"

Not having the JVM_VERSION flag leads to the same Buildpack v10.2.6 to be used and it defaults to JDK 17, which of course crashes since I am targeting JDK 21.

All the above was tested in Windows Powershell. Switching over to the Visual Code Native Image Command Prompt (ie using my local native-image) gives me similar results:

mvnw clean install -Dnative -Dquarkus.native.container-build=true works but did not seem to have used Buildpack
mvnw clean install -Dnative -Dquarkus.container-image.build=true does not work, noting that Build step io.quarkus.container.image.buildpack.deployment.BuildpackProcessor#buildFromNative threw an exception: java.lang.RuntimeException: The native binary produced by the build is not a Linux binary and therefore cannot be used in a Linux container image. Consider adding "quarkus.native.container-build=true" to your configuration
mvnw clean install -Dnative -Dquarkus.native.container-build=true -Dquarkus.container-image.build=true does invoke Buildpack and fails since it defaults to JDK 17
mvnw clean install -Dnative -Dquarkus.native.container-build=true -Dquarkus.container-image.build=true -Dquarkus.buildpack.builder-env.BP_JVM_VERSION=21 invokes Buildpack v10.2.6 and thus doesn't support JDK 21

Expected behavior

Native container builds to support JDK 21

Actual behavior

Native container builds select older version of Paketo Buildpack that does not support JDK 21

How to Reproduce?

./mvnw clean install -Dnative "-Dquarkus.container-image.build=true" "-Dquarkus.native.container-build=true" "-Dquarkus.buildpack.builder-env.BP_JVM_VERSION=21"

Output of `uname -a` or `ver`

Win 11

Output of `java -version`

java version "21.0.3" 2024-04-16 LTS

Mandrel or GraalVM version (if different from Java)

Java(TM) SE Runtime Environment Oracle GraalVM 21.0.3+7.1 (build 21.0.3+7-LTS-jvmci-23.1-b37)

Quarkus version or git rev

3.12.0

Build tool (ie. output of `mvnw --version` or `gradlew --version`)

Apache Maven 3.9.8 (36645f6c9b5079805ea5009217e36f2cffd34256)

Additional information

quarkus-bot[bot] commented 3 months ago

/cc @Karm (mandrel), @galderz (mandrel), @zakkak (mandrel)

jfslin commented 3 months ago

Ahh...I see that changing my pom from quarkus-container-image-buildpack to quarkus-container-image-jib as per https://quarkus.io/guides/container-image changes the build chain and allows me to try something else. I'll play around with the other container types and see.

jfslin commented 3 months ago

I was unable to get Jib to work properly, it froze freqently here:

[INFO] [io.quarkus.deployment.pkg.steps.NativeImageBuildRunner] docker run --env LANG=C --rm -v /c/github/target/back-rest-java-0.2.0-jib-native-image-source-jar:/project:z --entrypoint /bin/bash quay.io/quarkus/ubi-quarkus-mandrel-builder-image:jdk-21 -c objcopy --strip-debug back-rest-java-0.2.0-jib-runner
[INFO] [io.quarkus.container.image.jib.deployment.JibProcessor] Starting (local) container image build for native binary using jib.
[INFO] [io.quarkus.container.image.jib.deployment.JibProcessor] Using docker to run the native image builder
[WARNING] [io.quarkus.container.image.jib.deployment.JibProcessor] Base image 'quay.io/quarkus/quarkus-micro-image:2.0' does not use a specific image digest - build may not be reproducible
[INFO] [io.quarkus.container.image.jib.deployment.JibProcessor] Using base image with digest: sha256:c3be09c2057005d88962fd983a77c9131e29ea634ec324e3b99d5489504c1ea5
[INFO] [io.quarkus.container.image.jib.deployment.JibProcessor] Container entrypoint set to [./application]

But I was able to get Docker to build properly. Closing the issue for now.

quarkusio / quarkus