... as a PR, so that, when merged, other users can pull it into their build automatically, merely by looking up from the relevant dependency's maven coordinates.
You can also ship this metadata as part of the library artifact itself[1], by placing configurations at the JAR resource path `META-INF/native-image/<group-id>/<artifact-id>/reachability-metadata.json`, etc
Yes, I was planning to do that in the coming weeks when I find a few hours of time.
And didn't know about the second part quite interesting, I'll look into it thank you
One more data point: One can run the app with an agent, and then run actions in that app to execute the relevant code paths. This will generate the reflection json file automatically.
Weird coincidence. I work on a software cryptographic module and we worked on this exact same thing today and came to a similar solution.
This is great, but you should post it to: https://github.com/oracle/graalvm-reachability-metadata
... as a PR, so that, when merged, other users can pull it into their build automatically, merely by looking up from the relevant dependency's maven coordinates.
You can also ship this metadata as part of the library artifact itself[1], by placing configurations at the JAR resource path `META-INF/native-image/<group-id>/<artifact-id>/reachability-metadata.json`, etc
[1]: https://www.graalvm.org/latest/reference-manual/native-image...
Yes, I was planning to do that in the coming weeks when I find a few hours of time. And didn't know about the second part quite interesting, I'll look into it thank you
One more data point: One can run the app with an agent, and then run actions in that app to execute the relevant code paths. This will generate the reflection json file automatically.