chanseokoh
commented
1 year ago I understand one can think about the integration, which we did too. However, once you try to materialize such an idea, you'll soon realize that it doesn't make much sense.
Basically, Buildpacks and Jib cannot be compatible. spring-boot:build-image builds an image using Cloud Native Buildpacks in a black-box manner where it runs Docker to build artifacts (e.g., jars, native executable, etc.) inside containers to generate image layers to create an image. Cloud Native Buildpacks have their own way and workflow of building things inside containers. When using Cloud Native Buildpacks, to contribute your own layer to the final image to build, you need to write a buildpack. It's the only way to plug something into their workflow.
OTOH, Jib assembles an image directly out of files generated by Maven. Moreover, the mode of image building in Jib is fundamentally different: declarative vs. imperative, basically. Jib builds an image without running or requiring Docker (i.e., Jib describes the image), while Buildpacks build an image by executing a series of containers and commands inside Docker.
In any case, both spring-boot:build-image and native-image:native-image delegate the task to build a native executable to the native-image program.
Is there a future plan to integrate the Jib GraalVM Native Image Extension with Spring Native's specific build goals? Specifically, Spring Native can be compile by the user calling
$ mvn spring-boot:build-image, instead of using thenative-image:native-imagegoal. It would be very helpful if binaries compiled directly from spring native could be used with jib!Following the build steps as seen here.