feat: Add required reflection/resource metadata for native image generation
I hope the title is self-explanatory. Providing reflection metadata to Graal's native image generation would be a nice addition to the library. The Akka counterparts of the artifacts already had these in place, so the contents were trivial.
The Akka counterparts of the artifacts already had these in place, so the contents were trivial.
Does that mean you derived these artifacts from the Akka artifacts? What license were those Akka artifacts under? If they were BSL-licensed we cannot accept them in Pekko.
I'm a little concerned how we're going to keep those maintained as the library evolves. I remember there was an initiative to maintain such configurations outside of the main Akka tree, https://github.com/vmencik/akka-graal-config . If we could adapt such an approach, the Graal definitions could evolve independently from Pekko 'itself'. Would that be a feasible approach?
I guess the idea is that Graal users want these files included in our jars. And an outside group can still repackage the Pekko jars and add these files independently.
I haven't done a full review (currently using a mobile phone) but I didn't notice anything to continuously test these config s so that our CI could police changes.
And to reiterate @raboof 's point that we only accept PRs when the work is the submitter's original work. We will not accept code that is taken from Akka unless the submitter to Pekko is the original submitter to Akka. The code writer retains the copyright on the code and can choose to submit it Pekko.
About the content of the changes, they are simply JSON files that were generated via the native image agent running on the tests, that are in a schema that the native image executable accepts. Correct me if I'm wrong, but I am not sure if this could be considered copyright material or "original work" as it merely contains class paths, field types, etc. which reference the classes in the Pekko org. TBH, I did not double check if all the classes mentioned in the JSON files exist in the artifacts. But we can do due diligence if it is still a concern.
I didn't include the full workflow to keep these configurations updated because firstly, I wanted to gauge what everyone thinks about it, and secondly, it would be a lot of work and I thought it could be done in parts.
I would also be fine with having these in a separate project, but I think having them in Pekko itself can help with the release process. What do you think?
Fair enough about adding regression tests in a 2nd pass.
Could you write up how to generate these JSON files? Ideally someone else would be able to generate them too. We may even need to regenerate if we make certain changes in Pekko. If we know how the generate them that removes any lingering worries that these files were copied directly from Akka.
the file is generated with tools, but it's hard to cover every code paths, i think this better be a plug in for automatic generating instead of a static file