-
Notifications
You must be signed in to change notification settings - Fork 2.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Override items from super classes when generating config documentation #41979
Conversation
/cc @brunobat (opentelemetry) |
This comment has been minimized.
This comment has been minimized.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I added two small non-blocking comments. Feel free to either edit the commit or merge it as is :).
import io.smallrye.config.WithDefault; | ||
import io.smallrye.config.WithName; | ||
|
||
@ConfigGroup |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I know it's not mandatory but I would say it's a good practice to keep the annotation, given the annotation processor is annotation driven.
They get discovered anyway when analyzing the config but this makes it discovered right away by the AP.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
When this annotation is present in a super class relative to the mapping class, we do generate duplicate entries of the configuration, because we handle @ConfigGroup
as a nested element and not as an inherited element.
We could also fix that in the code, but I think that super classes are not config groups, so it is a bit misleading to add that annotation.
...rocessor/src/main/java/io/quarkus/annotation/processor/generate_doc/ConfigDocItemFinder.java
Outdated
Show resolved
Hide resolved
…enerate_doc/ConfigDocItemFinder.java Co-authored-by: Guillaume Smet <guillaume.smet@gmail.com>
Status for workflow
|
The fix could be better by using a
Map
instead of a dumbList
search, but we don't want to change the code too much due to some significant refactorings coming.