-
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
Support getting GraalVM version at native executable build time #43696
Support getting GraalVM version at native executable build time #43696
Conversation
* Moves core parts of `GraalVM.Version` to `io.quarkus.runtime` to enable us to use the functionality during native executable build time, e.g. from the generated `io.quarkus.runner.Feature` * Infers version from `org.graalvm.vendorversion` property * Avoids breaking existing API * Deprecates methods in the deployment package in favor of those in the runtime package, so that we can eliminate the former in the future.
* @param exportBefore the version of GraalVM before which the package should be exported (exclusive) | ||
* @deprecated use {@link #JPMSExportBuildItem(String, String, GraalVM.Version, GraalVM.Version)} instead | ||
*/ | ||
@Deprecated |
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 might be a bit confusing as it appears like I am adding a Deprecated
method, but I actually changed the import and deprecated the method with the old types.
Status for workflow
|
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.
LGTM. Any chance to have this class in org.graalvm.sdk:nativeimage
in the future?
Yes, that would make sense. Update: I created oracle/graal#9831 |
GraalVM.Version
toio.quarkus.runtime
toenable us to use the functionality during native executable build time,
e.g. from the generated
io.quarkus.runner.Feature
org.graalvm.vendorversion
propertyruntime package, so that we can eliminate the former in the future.
This PR restores the functionality we removed in #36037 to avoid the dependency on the polyglot API. Restoring the functionality allows us to generate
Feature
code conditionally as described in #25975 (comment) which I also need to implement #43533 (reply in thread) in #43448