Introduce @ConfigDocAttribute to inject asciidoc attributes in config root documentation #43808
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The problem is the following:
You can take the example of #39416.
Ideally, I'd just use
xref:#someanchor
and all would be fine: the link would be to the same page, no need to alter it based on context.But... we allow listing the documentation of configuration properties in other contexts than the extensions' main guide; for example in
all-config.adoc
. In such context, a link to the same page would not work.In this PR I tried to solve the problem by adding a
@ConfigDocAttribute
annotation. The idea would be that the config group in extension A references an AsciiDoc attribute (variable) to build its links, and each config root in extensions B and C would assign a different value to that attribute. You can see how it's used in practice in the last commit of #39416: 44d8359It worked well... until I noticed that you can only ever assign values to attributes outside of an asciidoc block. Critically, you cannot change attribute values in the middle of a table, which completely breaks the approach for
all-config.adoc
.So, submitting this for discussion... how would you rather we solve it, @gsmet?
At this point the only viable option seems to be some custom variable definition/replacement in the Quarkus tool suite: we'd still use something similar to
@ConfigDocAttribute
, but would substitute attribute references ourselves, either when rendering the Qute templates (e.g. inio.quarkus.maven.config.doc.generator.AbstractFormatter#formatDescription
), or (even better) when we generatequarkus-config-javadoc.yaml
.Alternatively we could have something less flexible, that doesn't allow custom attributes, but allows inserting links to the guide of the extension of the config root, with a parameterized anchor. That would still need to be handled by our own tools, though.