I looked through the non-core parts of the website and see that the subprojects generally have one or more “index tables” similar to the index tables for the “main” components component (and now the 3.2.x version of “components”).
I think it would be nice if these all had the same format and method of generation as the main ones. Looking briefly at the code, it’s not very clear to me how the information gets from human effort into the table. In order to use the “index extension” as in the “main” tables, the necessary information has to be available as asciidoc attributes in the pages to be included. It’s possible to do various bits of asciidoc magic so that these pages might not be the ones in the component component, but rather wrappers around them, but it would certainly be simpler if the info could be in the current pages. For the main camel components, IIUC the workflow is like this: 1. A developer annotations the actual java class 2. Something extracts these annotations and constructs a <component>.json file from the information. 3. In the camel maven packaging plugin UpdateReadmeMojo, this information is extracted from the .json file and translated into suitable header attributes. Here’s what I think I’ve discovered about the subprojects…. - Camel K: no components table, but there’s a traits list/table that could perhaps benefit from the same sort of treatment. - Camel Karaf: There’s a table of components that seems to be extracted from the feature file. — How is this feature file maintained or generated? — The existing table seems to have a second line under each component name such as 'activemq:destinationType:destinationName’ I can’t quite imagine what this is. (this shows up in quarkus and spring-boot-starter tables also) - Camel Kafka Connector: I don’t see any index tables - Camel Quarkus: Index tables “just like” in main components. I haven’t identified where the information for these comes from. - Camel Spring Boot Starters: Index tables “just like” in main components. I haven’t identified where the information for these comes from. Could experts on these subprojects explain the data flow? —— From my current point of view, everything would be simplest if the information about which “extensions” apply to a given component/language/data-format could be in the json file describing it; IIUC one way for it to get there would be to add the information to the base java class. I’d think this information might be more generally useful, studying a component you could see, "hmm this is available in karaf but not quarkus”. For instance, there could be a little table in each component page showing which subprojects it applies to or is available in. I don’t know how reliable maintaining this by hand would be or if maintenance could plausibly be automated. Thanks, David Jencks
