Open stuartwdouglas opened 4 years ago
technically this is feasible as what jbang does is basically generate a command for the wrapper script to run... BUT jbang presumes what it launches is a java process (i.e. passing system properties, vm arguments etc.) - that would not be a good match for the container image unless its entry point behaves like a java cmd ?
thinking on this i still think that jbang --native
should create exectuble using native-image on the platform raw.
container builds (using i.e. jib or similar) should do the build of native image in binary...then it would be consistent.
Quarkus can generate a container image as part of its integration build, but JBang will run the jar/executable instead of the container image. It would be cool if Quarkus generates a container image to have JBang actually run the container.
This would be useful for mac users that don't have GraalVM installed, as using docker to create the native executable will produce a linux executable.