Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Build native image source jar #15208

Closed
ebaron opened this issue Feb 19, 2021 · 6 comments · Fixed by #15233
Closed

Build native image source jar #15208

ebaron opened this issue Feb 19, 2021 · 6 comments · Fixed by #15233
Assignees
Labels
area/mandrel kind/enhancement New feature or request
Milestone

Comments

@ebaron
Copy link

ebaron commented Feb 19, 2021

Description
I would like the ability for Quarkus to produce a native image source jar without also running a native-image build. The scenario in mind is the following, with two machines:

  1. Maven builder machine with all needed dependencies, but no GraalVM/Mandrel.
  2. Container builder machine using a Mandrel builder image, but no Maven or dependencies. It has access to the output from the first machine.

I cannot find a way to perform a Maven build with Quarkus, such that the output jar can be passed to native-image and produce a working executable. When I give native-image the standard runner jar, or uber-jar, the executable exits immediately with exit code 1.

Implementation ideas
This functionality could perhaps be added as a package type selection for the quarkus.package.type property.

@ebaron ebaron added the kind/enhancement New feature or request label Feb 19, 2021
@quarkus-bot
Copy link

quarkus-bot bot commented Feb 19, 2021

/cc @galderz, @zakkak

@ebaron
Copy link
Author

ebaron commented Feb 19, 2021

/cc @jerboaa

@geoand
Copy link
Contributor

geoand commented Feb 22, 2021

This would be very easy to add, the question is whether we want to support it or not :)

cc @gsmet @stuartwdouglas

@jerboaa
Copy link
Contributor

jerboaa commented Feb 22, 2021

@geoand I've had a discussion about a similar workflow with @tqvarnst. The basic idea would be to do everything needed up to - but not including - running native-image. In fact, we've coined an idea of writing the native image command to a file (or just the native-image args) so as to be able to run the native-image command at a later stage. This would be helpful for a staged container build, and debugging native-image builds outside quarkus-maven-plugin. For the former, consider:

  1. Compile the Java files and produce necessary artefacts in tooling container A
  2. Run native-image on tooling container B using A's output (jar artefacts and native-image args)
  3. Take the result from B - the native image of the app - and put it into a runner image C

Each step along the way minimizes the needed dependencies in images A, B and C. A workflow like that could also be used in build pipelines. Please consider implementing this.

@geoand
Copy link
Contributor

geoand commented Feb 22, 2021

Understood.

I'll create a draft PR later on with a new package type as requested and we can discuss further based on that

@jerboaa
Copy link
Contributor

jerboaa commented Feb 22, 2021

Thanks!

@geoand geoand self-assigned this Feb 22, 2021
geoand added a commit to geoand/quarkus that referenced this issue Feb 22, 2021
This package type is meant to support workflows where the actual native-image is created by a different
container than the one that run that Quarkus build.

Resolves: quarkusio#15208
geoand added a commit to geoand/quarkus that referenced this issue Feb 22, 2021
This package type is meant to support workflows where the actual native-image is created by a different
container than the one that run that Quarkus build.

Resolves: quarkusio#15208
geoand added a commit to geoand/quarkus that referenced this issue Feb 22, 2021
This package type is meant to support workflows where the actual native-image is created by a different
container than the one that run that Quarkus build.

Resolves: quarkusio#15208
geoand added a commit to geoand/quarkus that referenced this issue Feb 22, 2021
This package type is meant to support workflows where the actual native-image is created by a different
container than the one that run that Quarkus build.

Resolves: quarkusio#15208
geoand added a commit to geoand/quarkus that referenced this issue Feb 22, 2021
This package type is meant to support workflows where the actual native-image is created by a different
container than the one that run that Quarkus build.

Resolves: quarkusio#15208
geoand added a commit to geoand/quarkus that referenced this issue Feb 22, 2021
This package type is meant to support workflows where the actual native-image is created by a different
container than the one that run that Quarkus build.

Resolves: quarkusio#15208
@quarkus-bot quarkus-bot bot added this to the 1.13 - master milestone Feb 23, 2021
geoand added a commit that referenced this issue Feb 23, 2021
Add native-source package type
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/mandrel kind/enhancement New feature or request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants