feat(client): publish GraalVM metadata files#534
Conversation
|
Curious what errors you ran into with Java 24 if you still have them? |
|
With Java 24, I had this error, using the configuration at https://github.com/jdubois/openai-java/blob/6a8d908bb52af8a4b2bea74786318dc161521f71/.github/workflows/test.yml , when running the tests: |
* feat(client): publish GraalVM metadata files (#534) * Generate the GraalVM metadata file(s) when releasing the project Fix #522 * Rename the GraalVM Agent profile to "graalvmAgent" * release: 2.16.0 --------- Co-authored-by: Julien Dubois <[email protected]> Co-authored-by: stainless-app[bot] <142633134+stainless-app[bot]@users.noreply.github.com>
|
Glad to see GraalVM support! Have you considered adding this library to this list on the GraalVM website?
|
|
@fniephaus I'd love to, however the file points to the metadata locations on GitHub, and those are not available: they are generated at release time, using the GraalVM agent, so there's nothing to point to in the repository. |
Not a problem, I think we'd accept something like this link: openai-java/.github/workflows/create-releases.yml Lines 58 to 68 in 2494220 |
|
Thanks! Done at oracle/graalvm-reachability-metadata#706 |
This adds support for generating the GraalVM metadata when releasing the project, as mentioned in #522
The setup is a bit complex because:
So the way this is done here is:
At some point this will all need to migrate to Java 24: at that moment, please note that GraalVM will have a new file format, and will generate only one file instead of several (but always in the same directory, so this code should still work OK).
I'm keeping the full "publish to Sonatype" task, to have everything fully compiled and tested for the release. That means the tests will run twice - this could be fixed by adding
-x testto that task.Another way to achieve this would be to use the GraalVM Gradle task instead of adding the agent library like we do here as a JVM argument: this seems more elegant, but that approach cannot work currently as it would require to import that task (the task only run when the "agent" profile is set up, but the import would always be there as they can't be conditionally imported). And as that task cannot run with Java 17, that would make the Kotlin build fail. This is something that could be improved later, when the project will work with Java 24.