Conversation
This entails a few things: - Move test class out of `io.quarkus.qute` package and instead use `add-opens`+reflection to get at items in that package - Change the default class generation target from `io.quarkus.qute` to `io.quarkus.qute.generated`
| <plugin> | ||
| <artifactId>maven-surefire-plugin</artifactId> | ||
| <configuration> | ||
| <argLine>--add-reads=io.quarkus.qute=java.logging</argLine> |
There was a problem hiding this comment.
No expert here, but is this to force the java.logging module into the module graph? Shouldn't --add-modules=java.logging be enough in that case?
There was a problem hiding this comment.
It's because the tests use JUL APIs to add handlers. Since the module doesn't normally require java.logging, the test code (which is patched into the module being tested by surefire using --patch-module) cannot load the classes which do this (because there's no "reads" edge). So we add a "reads" to the graph explicitly which allows the test class to be loaded.
I believe surefire always loads all of java.se which includes java.logging normally, so we don't need add-modules for this case.
Status for workflow
|
Add module descriptors to Qute components and ensure that tests pass.