-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
Add stable option for -H:IncludeResources and -H:ExcludeResources #7354
Comments
/cc @fniephaus |
Hi @jerboaa, thanks for raising this.
So -H:IncludeResources=Grace_M._Hopper.jp2,MyFreeMono.ttf,MyFreeSerif.ttf can be turned into the following {
"resources": {
"includes": [
{
"pattern": "Grace_M._Hopper.jp2"
},
{
"pattern": "MyFreeMono.ttf"
},
{
"pattern": "MyFreeSerif.ttf"
}
]
}
} I'm sure you can come up with a smarter pattern if you prefer that. |
@jerboaa also note that this is how Quarkus handles this (it generates a resource-config.json file). If you get the above message with Quarkus then it's probably due to a third party dependency passing the argument (e.g. by setting |
The build output tells you where the option is coming from:
So in this case, it seems to be a user-provided command-line argument. |
It seems a step backwards in terms of usability? First I need to generate a json, and then pass it to the |
We don't have any API options to register elements for reflection, JNI, etc. Why would we have that for resources? You don't need to add any additional option if the |
You can spin this both ways: with the config file, there is only one way to do the thing. We also provide tooling for the config files (e.g., for merging). |
Fair enough. Could I convince you to make this apparent in the build output? A link to a doc should suffice. I.e. to safe the next person from going down the rabbit whole of trying to figure out what the replacement is supposed to be. |
You don't have to convince me. 😉 The build output already prints alternative API options when available, but we didn't have time to implement support for more complex migration suggestions. The easiest solution in this case would be to deprecate |
Note that " exclude resources" needs to go away completely, because excluding resources in one native-image.properties file that another file included breaks composeability of libraries. But that is not really related to the option vs. the ability to exclude resources via the configuration files. |
I'm going to close this for now. #7370 tracks the request in #7354 (comment). |
This will be addressed by #7720. |
Describe the issue
With a GraalVM dev build (24.0) when
-H:IncludeResources=path/to/image.jpg
is being used it gets flagged as an experimental option. For example, in my case it produces the following warnings on thenative-image
invocation:As per the suggestion, I'm filing this issue to consider this as an API option. Or otherwise, how would one add resources to the image in 23.1+ without running into the experimental options issue?
The text was updated successfully, but these errors were encountered: