-
Notifications
You must be signed in to change notification settings - Fork 2.7k
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
Fix broken native build of generated projects #5005
Conversation
@gsmet can you try it out? Asking because I know you could reproduce the issue |
I sure will. |
One thing we need is to move one of the current IT to the new way of doing things. It’s not acceptable to discover this by pure luck. |
My hypothesis is that this fails because the class is reinitialized, but the static init does some things that are disallowed during native image run time. I think this class cannot be reinitialized at run time. Instead I think we'll have to reinitialize specific fields manually. |
I can do that in a follow up |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So I confirm it fixes the issue for me too and with a newly created simple project, I'm now able to create a native image.
I think we need Stuart to confirm if that's the right fix though.
For Stuart:
- create a project with
mvn io.quarkus:quarkus-maven-plugin:999-SNAPSHOT:create -DprojectGroupId=org.acme -DprojectArtifactId=getting-started -DclassName="org.acme.quickstart.GreetingResource" -Dpath="/hello" -Dextensions="openapi"
cd getting-started
mvn clean install -Dnative
will fail with a NPE in BuildMojo at line 190- with the
if
Georgios added, we pass this step but then we have another NPE that the change of default value for the full stacktrace somehow fixes.
@@ -165,7 +165,7 @@ | |||
/** | |||
* If full stack traces are enabled in the resulting image | |||
*/ | |||
@ConfigItem(defaultValue = "false") | |||
@ConfigItem(defaultValue = "true") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, this is definitely dark magic.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This change was unintentional. I must have made a mistake when creating this, or maybe it got missed in one of the many rebases.
} | ||
if (result.getJar().isUberJar()) { | ||
projectHelper.attachArtifact(project, result.getJar().getPath().toFile(), "runner"); | ||
if (result.getJar() != null) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure if the issue is the null test or the fact that result.getJar()
is empty. When using XML config, it's not as we don't have the NPE so I think we need Stuart to say if it's normal or not.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is ok, the NativeImageMojo does not attempt to look at the jar result.
@@ -165,7 +165,7 @@ | |||
/** | |||
* If full stack traces are enabled in the resulting image | |||
*/ | |||
@ConfigItem(defaultValue = "false") | |||
@ConfigItem(defaultValue = "true") | |||
public boolean fullStackTraces; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What bugs me a bit too is that now, the output when creating the native image is very scarce. I don't know if it's normal or not but we used to have a couple of Quarkus lines and now we have:
21:02:57,864 INFO [org.jbo.threads] JBoss Threads version 3.0.0.Final
and that's it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I will look into this
I honestly don't know why stacktraces need to be enabled for the generated native image to work properly.
Without this fix, the native image build of the generated (via the maven tooling) projects would fail: