Skip to content
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

Introduce @ConfigDocAttribute to inject asciidoc attributes in config root documentation #43808

Closed
wants to merge 1 commit into from

Conversation

yrodiere
Copy link
Member

@yrodiere yrodiere commented Oct 10, 2024

The problem is the following:

  1. I have a config group defined in extension A.
  2. Extensions B and C each have a config root, which uses the config group from extension A.
  3. The documentation of that config group needs to link to a section of a guide.
  4. The link to the guide of extension B and C would be different, since each has its own guide.

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: 44d8359

It 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. in io.quarkus.maven.config.doc.generator.AbstractFormatter#formatDescription), or (even better) when we generate quarkus-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.

@yrodiere yrodiere requested a review from gsmet October 10, 2024 13:05
@quarkus-bot quarkus-bot bot added area/core area/devtools Issues/PR related to maven, gradle, platform and cli tooling/plugins labels Oct 10, 2024
Copy link

🎊 PR Preview aa93848 has been successfully built and deployed to https://quarkus-pr-main-43808-preview.surge.sh/version/main/guides/

  • Images of blog posts older than 3 months are not available.
  • Newsletters older than 3 months are not available.

@gsmet
Copy link
Member

gsmet commented Oct 17, 2024

I think we can close this in favor of #43943 which looks like a better approach as discussed earlier this week.

@gsmet gsmet closed this Oct 17, 2024
@quarkus-bot quarkus-bot bot added the triage/invalid This doesn't seem right label Oct 17, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/core area/devtools Issues/PR related to maven, gradle, platform and cli tooling/plugins triage/invalid This doesn't seem right
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants