Conversation
|
What I did:
Hey @gsmet - it would be very nice if you could check if I missed something in the configs. 😃 |
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files☔ View full report in Codecov by Sentry. |
|
Important: If there are any new classes that requires reflections those need to be added to the configs as well as they are not auto generated via Spring / Quarkus |
d83066b to
12a5dcc
Compare
|
I had to force push as I forgot the |
bitwiseman
left a comment
There was a problem hiding this comment.
@klopfdreh
Thanks for giving this a try. This PR avoids the dependency, but it introduces a manual step for any time a class is added or removed. I'm not opposed this outright, but if you're going to go this route, there needs to be a test that checks that all expected classes are present in the file.
|
@klopfdreh Also, it looks like you're registering all the classes in The difficulty here is that we don't have a way of indicating what classes should and shouldn't be in the file. Added some notes to #1908 just for reference... Here's my thought on how to proceed:
This will ensure the files are maintained but also have low cost to maintain them. How does this sound to you? |
|
For me this sounds a bit odd that you want to handle both classes with/without reflections, as you already know from the reflect-config.json which classes use them, meaning all others don't use reflection. You can't get a list with classes that require reflection as this is something you need to know and define via spring-aot. I agree that it is much nicer to find out if you missed a class in the reflect-config.json during build time, but the only way to see if it is working is to start a native image in your pipeline (which is expensive). Note: It is not that big of a deal to add all classes to reflect and serialization as it is like in the JVM. The performance impact is also very low (I tested it already). What I suggest would be to add a test that uses spring-aot and checks via Registrar if all classes are mentioned in the reflect-config.json. To use reachable meta data for generating the reflect-config.json is risky as you have to have a 100% test coverage all the time. |
|
In the Quarkus extension, we have a test that approximates things a bit, meaning we have a list of excluded classes and any time a class gets added, we have to decide if we exclude it or add it: https://github.com/quarkiverse/quarkus-github-api/blob/main/deployment/src/test/java/io/quarkiverse/githubapi/deployment/GitHubApiDotNamesTest.java#L28 . It has worked well enough for us even if not ideal. |
|
BTW, I still think that having an annotation and an annotation processor would make things a bit easier. People wouldn't have to adjust the JSON file, which can be error prone, they would just have to add an annotation. |
I agree to this suggestion. It is a bit on the bare minimum side, but I would accept this. Can the test also update the json file (and then report failure)? That would address @gsmet's concern about maintaining the json file.
This is basically lines up with what I was thinking around not registering classes for reflection which don't need it. What this test shows is that having an exclude list is not expensive and it lets us check "all classes except a specific list are mentioned in the reflect-config.json". If you're willing to do this @klopfdreh, that would be even better but not absolute required. |
|
@bitwiseman - I am going to add the test, tomorrow. Even if this is a manual effort to add the entry into the reflect-config.json I would not let a test change the source code. (It is still only a test) |
|
Then If possible make the output when the test fails clear instructions about what to change. |
cbe105a to
c1d73b9
Compare
|
Hey @bitwiseman - I added the test now. Things which are important:
I have Java > 17 installed locally and already tested that if you run |
d127886 to
61cf034
Compare
61cf034 to
529f044
Compare
0deab6b to
c35001f
Compare
9f54fc2 to
dd53d7c
Compare
| @@ -0,0 +1,91 @@ | |||
| org.kohsuke.github.AbuseLimitHandler | |||
There was a problem hiding this comment.
I'm still not sure this list is correct, but issues here can be addressed as bug fixes.
bitwiseman
left a comment
There was a problem hiding this comment.
@klopfdreh
Great work!
@gsmet
This looks good to me. Please review and approve if you agree.
|
I'm going to merge this. @gsmet if you have any changes, please file an issue and tag @klopfdreh . |
Description
This PR will enable the
github-apito be supported by GraalVM. There have been two options discussed.@bitwiseman preferred option 2 as it reduces the dependencies and lower the costs.
The See #1908 for more information
Before submitting a PR:
@linkJavaDoc entries to the relevant documentation on https://docs.github.com/en/rest .mvn -D enable-ci clean install sitelocally. If this command doesn't succeed, your change will not pass CI.main. You will create your PR from that branch.When creating a PR: