Some build items are missing in documentation

[knutwannheden]

Describe the bug

The Jbang script generating the https://quarkus.io/guides/all-builditems documentation overview page currently only includes build items which are defined in source files ending in BuildItem.java (see

quarkus/.github/quarkusbuilditemdoc.java

Line 96 in adf1beb

if (file.toString().endsWith("BuildItem.java")) {

). There are however also build items which either don't adhere to this convention (e.g. Capabilities) or are defined as nested classes (e.g. in the processor class). As a result some build items are missing in the generated overview page.

Expected behavior

All (public?) build items should be included in the generated overview page.

Actual behavior

See description.

[quarkus-bot]

/cc @maxandersen, @quarkusio/devtools

[gsmet]

/cc @gastaldi

[shoebxsiddiqui]

I want to work on this.

[delongmeng-aws]

I'd like to work on this, but it will be very helpful if you can give more instructions on which ones should be included here (besides the ones ending with "BuildItems.java") and how to find them? @knutwannheden

[delongmeng-aws]

Hi how do I link my pull request to this issue? I couldn't edit the "Linked issues" option there. #22011 @knutwannheden

[gastaldi]

Sorry, this issue fell through the cracks. I think Capabilities is an exception to the rule, we can hardcode that in the generator. Other build items like ProcessInheritIODisableare being deprecated in favor of the BuildItem suffix (see #22081).

I'm a bit torn on nested build item classes, IMHO we shouldn't list in the config document, since it most likely it was created to be an implementation detail and used internally

[knutwannheden]

@gastaldi I couldn't find any other exceptions to this rule either. I don't know exactly when this tool runs, but I was naively assuming that it should be possible to let it either scan the Java class files (using some library) or even the files produced by the Quarkus APT itself to process all build items properly (similarly as for the @ConfigRoot annotations for the config reference). But if indeed some build items are to be regarded as internal, this would require some other explicit mechanism (like a naming convention or some annotation attribute) to declare a build item as internal.

[gsmet]

I think this one is pretty much covered now.