I’ve supplied PRs for CAMEL-14906 <https://issues.apache.org/jira/browse/CAMEL-14906> and CAMEL-14907 <https://issues.apache.org/jira/browse/CAMEL-14907>.
I put up a preview showing both these changes: https://camel-preview-1.s3-us-west-2.amazonaws.com/manual/latest/index.html#_components_data_formats_languages_and_enterprise_integration_patterns https://camel-preview-1.s3-us-west-2.amazonaws.com/components/latest/index.html <https://camel-preview-1.s3-us-west-2.amazonaws.com/components/latest/index.html> Are these improvements? Somehow the component counts disappeared from the previous commits, so if 14907 is rejected they’ll need to be added back. Thanks David Jencks > On Apr 14, 2020, at 9:21 PM, David Jencks <david.a.jen...@gmail.com> wrote: > > Having closed the issue for this, CAMEL-14874 > <https://issues.apache.org/jira/browse/CAMEL-14874>, I’ve opened a bunch of > follow-on issues, some of which I will work on if they seem like a good idea. > > The first two I don’t expect to work on, unless the solution to the 2nd is to > disable the extensions causing the problem. > > CAMEL-14904 <https://issues.apache.org/jira/browse/CAMEL-14904> Nav pane does > not show current page > > CAMEL-14905 <https://issues.apache.org/jira/browse/CAMEL-14905> "responsive" > table settings make it impossible to set reasonable column sizes. > > The next three I’m happy to work on. > CAMEL-14906 <https://issues.apache.org/jira/browse/CAMEL-14906> user manual > index page should not list entire contents of another component. > CAMEL-14907 <https://issues.apache.org/jira/browse/CAMEL-14907> Consider > separating core and non-core components in the components index page > > CAMEL-14908 <https://issues.apache.org/jira/browse/CAMEL-14908> Consider > generating component index tables with Antora in 3.2.x branch and possibly > 2.x branch. > > The last two require some discussion before proceeding. > > CAMEL-14909 <https://issues.apache.org/jira/browse/CAMEL-14909> Decide what > to do with bindy component(s) doc page(s) > > CAMEL-14910 <https://issues.apache.org/jira/browse/CAMEL-14910> Decide if > component summary pages are a good idea > > There’s also > CAMEL-14866 <https://issues.apache.org/jira/browse/CAMEL-14866> camel website > - Show on component table the supportLevel > The support level is now shown in text, combined with the deprecated state. > If someone comes up with icons I can use them or indicate how to use them. > > thanks > David Jencks > > >> On Apr 14, 2020, at 2:50 PM, David Jencks <david.a.jen...@gmail.com >> <mailto:david.a.jen...@gmail.com>> wrote: >> >> I think this stage of this work is done, I’ve opened PRs for the 5 >> repo/branches involved. >> >> There’s a preview at >> https://camel-preview-1.s3-us-west-2.amazonaws.com/manual/latest/index.html >> <https://camel-preview-1.s3-us-west-2.amazonaws.com/manual/latest/index.html> >> of the Antora part of the site. I haven’t been able to build the hugo part >> for quite a while, but don’t have any interest in investigating why. >> >> My build turns off the responsive table extensions, as they mangle the table >> layout and make it almost unreadable. My PR doesn’t do this however. >> >> Current state of the things mentioned below: >> >> - support level includes text combining plain support level and deprecation. >> >> - There’s only one link to the bindy data formats. I can think of lots of >> other possibilities but lets work that out later. >> >> - After looking at all the mystery pages I decided that they are actually >> useful summaries of collections of components. They now appear in the nav >> list at the head of the things they summarize and in the index table above >> the things they summarize. (the spring-main page is actually a poorly >> documented component, now appropriately classified). >> >> >> I changed the adoc processing in UpdateReadmeMojo quite a bit: >> - It now generates all the header information in one go. >> - It makes no attempt however feeble to lint the adoc. >> - It makes no attempt to second guess the nature of some required strings, >> but fails the build immediately if they aren’t present. The previous code >> was missing all sorts of problems, which I cleaned up by hand. The required >> strings are: >> >> For all component-like files: >> *Since Camel {since}* >> >> For components: >> >> *{component-header}* >> >> One comment inline…. >> >> Thanks >> David Jencks >> >>> On Apr 14, 2020, at 12:34 AM, Claus Ibsen <claus.ib...@gmail.com >>> <mailto:claus.ib...@gmail.com>> wrote: >>> >>> On Fri, Apr 10, 2020 at 6:31 PM David Jencks <david.a.jen...@gmail.com >>> <mailto:david.a.jen...@gmail.com>> wrote: >>>> >>>> Thanks for the feedback! >>>> >>>> Combining two fields in the json into one column doesn’t make sense to me. >>>> Wouldn’t it be better to add a ‘deprecated’ state to the supportLevel >>>> state machine? IIUC there’s an idea to replace the words in the support >>>> level column with an icon so the wording may not matter too much, e.g. the >>>> name of the state could be stable-deprecated. It would certainly be great >>>> if there were fewer columns :-) >>>> >>> >>> Hmm how would an icon represent this that would be easily understood? >>> On top of my mind I cant picture something that says that - only gold, >>> silver, bronze badges. >>> >> >> I’m not a graphic designer, but I assume that the icons would combine a >> color and letter or symbol. If the “stable" icon was say an S on a gold >> background, the “deprecated” could be a paler S on a grey background. >> >>> >>>> I don’t understand your ideas about bindy. The current site has three >>>> links to exactly the same page. I think that is excessively confusing. >>>> If there are really three flavors of bindy that ought to be explained >>>> differently, then IMO there ought to be three .adoc pages, one for each. >>>> The table generation I’m using works off of pages, not json files, so >>>> there’s no way to get three links to the same page. I might be able to >>>> produce 2 extra page aliases to the one page and have links to them, but >>>> that’s silly. >>>> >>> >>> There are 3 variations of bindy and they share some common as well. >>> Its a hazzle to splitup the old doc into three, and therefore they >>> point to the same doc. >>> >>>> With regard to the 6 json-less miscellaneous pages, I think either they >>>> should be linked to from somewhere obvious or removed completely. They >>>> aren’t just folders, there are actual pages linked to, that someone wrote. >>>> Here are the pages in the current website. They are linked to from the >>>> nav menu but not in any table. Please look at them and decide if they are >>>> current and useful or obsolete and should be removed. >>>> >>>> https://camel.apache.org/components/latest/azure.html >>>> <https://camel.apache.org/components/latest/azure.html> >>>> <https://camel.apache.org/components/latest/azure.html >>>> <https://camel.apache.org/components/latest/azure.html>> >>> >>> Delete >>> >>>> https://camel.apache.org/components/latest/ignite.html >>>> <https://camel.apache.org/components/latest/ignite.html> >>>> <https://camel.apache.org/components/latest/ignite.html >>>> <https://camel.apache.org/components/latest/ignite.html>> >>> >>> Delete >>> >>>> https://camel.apache.org/components/latest/kubernetes.html >>>> <https://camel.apache.org/components/latest/kubernetes.html> >>>> <https://camel.apache.org/components/latest/kubernetes.html >>>> <https://camel.apache.org/components/latest/kubernetes.html>> >>> >>> Delete >>> >>>> https://camel.apache.org/components/latest/openstack.html >>>> <https://camel.apache.org/components/latest/openstack.html> >>>> <https://camel.apache.org/components/latest/openstack.html >>>> <https://camel.apache.org/components/latest/openstack.html>> >>> >>> Delete >>> >>>> https://camel.apache.org/components/latest/spring-main.html >>>> <https://camel.apache.org/components/latest/spring-main.html> >>>> <https://camel.apache.org/components/latest/spring-main.html >>>> <https://camel.apache.org/components/latest/spring-main.html>> >>> >>> Keep >>> >>>> https://camel.apache.org/components/latest/spring.html >>>> <https://camel.apache.org/components/latest/spring.html> >>>> <https://camel.apache.org/components/latest/spring.html >>>> <https://camel.apache.org/components/latest/spring.html>> >>>> >>> >>> Keep >>> >>> >>> >>>> If these are current, maintained, summary pages that should be kept, then >>>> I’d suggest linking to them from each related component that they >>>> summarize. They should also be renamed so as to end up in the main >>>> components nav as they certainly don’t refer to “other” components. >>>> >>>> To merge in Guillaume's comments back into the same thread… >>>> >>>> I’ll see if I can find a plausible way to shorten some of the columns. >>>> >>>> I know about the wide/narrow button, but wide is going to remove the “on >>>> this page” TOC that I hope gets merged in soon, and narrow doesn’t use >>>> most of the actual screen space, at least on my display. >>>> >>>> The code in UpdateReadmeMojo seems rather peculiar to me, I’m going to see >>>> if I can simplify it a bit to put all the header generation in one method. >>>> In general it seems to me that it should not be trying to lint the adoc >>>> source and update it; it should perhaps find peculiar usages and perhaps >>>> fail, but auto-updating is weird. >>> >>> Its not weird - A lot of the docs are auto updated and thats what we want. >>> >>> >>> >>>> >>>> Thanks! >>>> >>>> David Jencks >>>> >>>>> On Apr 9, 2020, at 11:40 PM, Claus Ibsen <claus.ib...@gmail.com >>>>> <mailto:claus.ib...@gmail.com>> wrote: >>>>> >>>>> On Fri, Apr 10, 2020 at 7:58 AM David Jencks <david.a.jen...@gmail.com >>>>> <mailto:david.a.jen...@gmail.com> <mailto:david.a.jen...@gmail.com >>>>> <mailto:david.a.jen...@gmail.com>>> wrote: >>>>>> >>>>>> I have most of the basic work for this done. I’ve pushed a preview of >>>>>> the current state of the Antora generated site to >>>>>> https://camel-preview-1.s3-us-west-2.amazonaws.com/components/latest/others/index.html >>>>>> >>>>>> <https://camel-preview-1.s3-us-west-2.amazonaws.com/components/latest/others/index.html> >>>>>> >>>>>> <https://camel-preview-1.s3-us-west-2.amazonaws.com/components/latest/others/index.html >>>>>> >>>>>> <https://camel-preview-1.s3-us-west-2.amazonaws.com/components/latest/others/index.html>> >>>>>> >>>>>> <https://camel-preview-1.s3-us-west-2.amazonaws.com/components/latest/others/index.html >>>>>> >>>>>> <https://camel-preview-1.s3-us-west-2.amazonaws.com/components/latest/others/index.html> >>>>>> >>>>>> <https://camel-preview-1.s3-us-west-2.amazonaws.com/components/latest/others/index.html >>>>>> >>>>>> <https://camel-preview-1.s3-us-west-2.amazonaws.com/components/latest/others/index.html>>> >>>>>> (the new page). >>>>>> >>>>>> The source is in branches named issue-14874-generate-index-tables in >>>>>> https://github.com/djencks/camel-website.git >>>>>> <https://github.com/djencks/camel-website.git><https://github.com/djencks/camel-website.git >>>>>> <https://github.com/djencks/camel-website.git>> and >>>>>> https://github.com/djencks/camel.git >>>>>> <https://github.com/djencks/camel.git> >>>>>> <https://github.com/djencks/camel.git >>>>>> <https://github.com/djencks/camel.git>>. >>>>>> >>>>>> As a side note, i’ve left the website playbook set up to build from the >>>>>> “PR branch” (although there’s no PR yet). With the new playbook >>>>>> organization this is really easy. >>>>>> >>>>>> Mostly old and new tables line up well. >>>>>> >>>>> >>>>> Great work David. I like the new table layout. One suggestion would be >>>>> to remove the deprecated column, and instead add that to the Support >>>>> Level column, so it would say: Stable (Deprecated) instead. As I think >>>>> it takes up to much empty space by default mode (not wide) and 99% of >>>>> the components will not be deprecated. >>>>> >>>>> Also this may have too much "noise" between the component name and the >>>>> description - that the most needed information for end users, to see >>>>> the list and find out what they do. Then information about "since" is >>>>> a bit secondary - but a great detail to see how "new the component >>>>> is". >>>>> >>>>> >>>>>> There are 6 “miscellaneous” components that appeared and don’t seem to >>>>>> have json files to extract attributes from. mostly they look like >>>>>> summary pages for collections of related components. AFAICT they aren’t >>>>>> linked to in the current site. What should happen to them? In the >>>>>> (new) miscellaneous table they have nothing outside the first column. I >>>>>> don’t know what to do with these, and without advice I’m just going to >>>>>> leave them. >>>>>> >>>>> >>>>> They are empty folders to group components, and should be skipped in >>>>> the table. In other words if there is no json metadata then they >>>>> should not be included. >>>>> In the future we would move for example the AWS components into its >>>>> own "folder" instead of having 20+ in the components folder. >>>>> >>>>>> In Dataformats, there’s now one one Bindy row instead of 3. Since all >>>>>> the old rows linked to the same document, same position, I think this is >>>>>> fine. >>>>>> >>>>> >>>>> Ah yeah bindy is a bit special as it has 3 dataformats out of the box, >>>>> and there should be 3 json files in its JAR. In other words "forget >>>>> about folders" but work with the json files - they are the source of >>>>> truth. >>>>> https://github.com/apache/camel/tree/master/components/camel-bindy/src/generated/resources/org/apache/camel/dataformat/bindy >>>>> >>>>> <https://github.com/apache/camel/tree/master/components/camel-bindy/src/generated/resources/org/apache/camel/dataformat/bindy><https://github.com/apache/camel/tree/master/components/camel-bindy/src/generated/resources/org/apache/camel/dataformat/bindy >>>>> >>>>> <https://github.com/apache/camel/tree/master/components/camel-bindy/src/generated/resources/org/apache/camel/dataformat/bindy>> >>>>> >>>>>> Languages line up exactly AFAICT. >>>>>> >>>>>> There are a couple new rows in components according to the count, but I >>>>>> haven’t found them yet. >>>>>> >>>>>> A couple of other comments: >>>>>> >>>>>> - On my laptop, the table does not make good use of the page width. >>>>>> It’s centered, crammed into the middle of the screen, too narrow, and >>>>>> with gigantic left margin. >>>>>> >>>>>> - I believe the Antora default UI makes sure that the navigation item >>>>>> corresponding to the current page is visible when you click on it. This >>>>>> doesn’t seem to be working for me, it goes to the top of the nav list. >>>>>> This is pretty confusing for me. >>>>>> >>>>>> Comments very welcome. >>>>>> >>>>>> David Jencks >>>>>> >>>>>> >>>>>>> On Apr 7, 2020, at 10:20 AM, David Jencks <david.a.jen...@gmail.com >>>>>>> <mailto:david.a.jen...@gmail.com> <mailto:david.a.jen...@gmail.com >>>>>>> <mailto:david.a.jen...@gmail.com>>> wrote: >>>>>>> >>>>>>> This is a bit of a multi-threaded reply :-) >>>>>>> >>>>>>> Guillaume asked about when this would happen. >>>>>>> >>>>>>> There are two stages. >>>>>>> >>>>>>> 1. The already existing use of UpdateReadmeMojo.java to copy info from >>>>>>> json into the component (etc) adoc pages is extended to put suitable >>>>>>> attributes into the doc header. (I think this answers one of Zoran’s >>>>>>> questions also) >>>>>>> >>>>>>> 2. The website Antora build uses the extension to query this info and >>>>>>> build the summary and table. There could be also a “sub-site for >>>>>>> latest” playbook in the docs master branch to build all the “latest” >>>>>>> components, that could also use this. In any case, it occurs when >>>>>>> Antora builds a site. >>>>>>> >>>>>>> The result is a static page, just like now, but with tables generated >>>>>>> from what’s in the content catalog, rather than directly from what’s in >>>>>>> some json files. (the options tables in the individual component pages >>>>>>> are still generated from the json files). The “generate summary tables >>>>>>> on index pages” mojo wouldn’t be needed any more, and the explicitly >>>>>>> visible list of components in the current index page would be removed. >>>>>>> I left it in for the preview for easy comparison. >>>>>>> >>>>>>> Other questions/answers: >>>>>>> >>>>>>> - The link text in the first column is the target page doctitle. Right >>>>>>> now, eliminating “component” from that would involve renaming the pages >>>>>>> from e.g. “ActiveMQ Component” to “ActiveMQ”. Would that be reasonable? >>>>>>> If not, I hadn’t previously considered it, but I supposed I could >>>>>>> introduce some fancier syntax to use another doc attribute as the link >>>>>>> text. That would introduce a slightly redundant attribute to every >>>>>>> page, for instance along with the doc title ‘= ActiveMQ Component’ >>>>>>> there’d be ‘:link-text: ActiveMQ’. I suppose the title could use the >>>>>>> attribute: ‘= {link-text} Component’. >>>>>>> >>>>>>> - I think the catalog labels mentioned are in the individual component >>>>>>> json files. If so, it would be very easy to turn them into .adoc >>>>>>> attributes and then put them into a column in the Antora generated >>>>>>> table. However, it’s still static html. Making it more interactive is >>>>>>> making it less of a static site, at which I am not an expert :-) I >>>>>>> can think of two approaches: one is to generate a lot of static tables >>>>>>> and hide most of them, which would fit with using this extension. The >>>>>>> other is to generate some data, presumably as json included in the >>>>>>> page, and have some client side javascript to filter based on fields >>>>>>> and render the table into html on the client. If there’s strong >>>>>>> support for this latter idea I might be able to add a processor to the >>>>>>> extension to generate the json. I’m not sure I want to learn how to >>>>>>> generate the tables at runtime, someone else might need to do that. >>>>>>> I’d suggest doing this later after what I’m proposing now has >>>>>>> stabilized. >>>>>>> >>>>>>> - It might also be possible to have a sort-by parameter for the >>>>>>> extension so the components are sorted by, for example, label and then >>>>>>> name. We’re rapidly getting into complex report generation here :-) >>>>>>> For instance the labels could be turned into a list, and for each item >>>>>>> a table with the components with that label value. And the >>>>>>> producer/consumer info could be shown somehow…. For me, something like >>>>>>> this would be a lot easier than a client-side table renderer. >>>>>>> >>>>>>> I hope that answers all the questions so far. >>>>>>> >>>>>>> Thanks, >>>>>>> David Jencks >>>>>>> >>>>>>>> On Apr 7, 2020, at 2:41 AM, Andrea Cosentino <anco...@gmail.com >>>>>>>> <mailto:anco...@gmail.com> <mailto:anco...@gmail.com >>>>>>>> <mailto:anco...@gmail.com>> <mailto:anco...@gmail.com >>>>>>>> <mailto:anco...@gmail.com><mailto:anco...@gmail.com >>>>>>>> <mailto:anco...@gmail.com>>>> wrote: >>>>>>>> >>>>>>>> Maybe we can also review the labels a bit and reducing the number >>>>>>>> >>>>>>>> Il mar 7 apr 2020, 11:40 Claus Ibsen <claus.ib...@gmail.com >>>>>>>> <mailto:claus.ib...@gmail.com> <mailto:claus.ib...@gmail.com >>>>>>>> <mailto:claus.ib...@gmail.com>> <mailto:claus.ib...@gmail.com >>>>>>>> <mailto:claus.ib...@gmail.com><mailto:claus.ib...@gmail.com >>>>>>>> <mailto:claus.ib...@gmail.com>>>> ha scritto: >>>>>>>> >>>>>>>>> Hi >>>>>>>>> >>>>>>>>> I would like to see the webpage be more interactive, in terms of we >>>>>>>>> have a fixed set of labels to quickly filter the component list. >>>>>>>>> So you can chose "cloud" or "database" or "file" etc. >>>>>>>>> >>>>>>>>> We have those labels today in the camel-catalog. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On Tue, Apr 7, 2020 at 11:31 AM Zoran Regvart <zo...@regvart.com >>>>>>>>> <mailto:zo...@regvart.com> <mailto:zo...@regvart.com >>>>>>>>> <mailto:zo...@regvart.com>> <mailto:zo...@regvart.com >>>>>>>>> <mailto:zo...@regvart.com><mailto:zo...@regvart.com >>>>>>>>> <mailto:zo...@regvart.com>>>> wrote: >>>>>>>>>> >>>>>>>>>> Hi David, >>>>>>>>>> I like where this is heading, what I like the most is that the >>>>>>>>>> templating is done in Asciidoc based on data in the component's >>>>>>>>>> documentation, this feels like the right approach as it allows >>>>>>>>>> remixing the content as needed. For a silly example, say we wish to >>>>>>>>>> have a page that lists all the messaging components or all AWS >>>>>>>>>> components, seems to me that would be fairly easy by creating a >>>>>>>>>> document indexing over an attribute -- we would need to add the >>>>>>>>>> category or label attribute for those examples. >>>>>>>>>> >>>>>>>>>> What I wonder though, is how do we maintain the attributes in the >>>>>>>>>> component Asciidoc files? You mention JSON to Asciidoc tool, would it >>>>>>>>>> be possible to have the Asciidoc file and JSON file side by side? >>>>>>>>>> There's some talk on Camel catalog, could we leverage that? That way >>>>>>>>>> we would have attributes in the catalog JSON file and documentation >>>>>>>>>> in >>>>>>>>>> adoc files. >>>>>>>>>> >>>>>>>>>> zoran >>>>>>>>>> >>>>>>>>>> On Tue, Apr 7, 2020 at 6:21 AM David Jencks >>>>>>>>>> <david.a.jen...@gmail.com <mailto:david.a.jen...@gmail.com> >>>>>>>>>> <mailto:david.a.jen...@gmail.com <mailto:david.a.jen...@gmail.com>> >>>>>>>>>> <mailto:david.a.jen...@gmail.com <mailto:david.a.jen...@gmail.com> >>>>>>>>>> <mailto:david.a.jen...@gmail.com <mailto:david.a.jen...@gmail.com>>>> >>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>> I’ve written an asciidoctor extension that queries the Antora >>>>>>>>>>> content >>>>>>>>> catalog and constructs simple reports. We might be able to use this >>>>>>>>> to >>>>>>>>> have Antora generate the index tables in the components component. >>>>>>>>>>> >>>>>>>>>>> The basic idea is to have the documentation generator transfer some >>>>>>>>> information from the json file to document attributes in the .adoc >>>>>>>>> page. >>>>>>>>> These are then available to use for selection or results in a query. >>>>>>>>>>> >>>>>>>>>>> I set up a preview of the current state of the Antora portion of the >>>>>>>>> website. For some reason the hugo portion is not building for me. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>> https://camel-preview-1.s3-us-west-2.amazonaws.com/components/latest/index.html >>>>>>>>> >>>>>>>>> <https://camel-preview-1.s3-us-west-2.amazonaws.com/components/latest/index.html> >>>>>>>>> >>>>>>>>> <https://camel-preview-1.s3-us-west-2.amazonaws.com/components/latest/index.html >>>>>>>>> >>>>>>>>> <https://camel-preview-1.s3-us-west-2.amazonaws.com/components/latest/index.html>> >>>>>>>>> >>>>>>>>> <https://camel-preview-1.s3-us-west-2.amazonaws.com/components/latest/index.html >>>>>>>>> >>>>>>>>> <https://camel-preview-1.s3-us-west-2.amazonaws.com/components/latest/index.html><https://camel-preview-1.s3-us-west-2.amazonaws.com/components/latest/index.html >>>>>>>>> >>>>>>>>> <https://camel-preview-1.s3-us-west-2.amazonaws.com/components/latest/index.html>>> >>>>>>>>> < >>>>>>>>> https://camel-preview-1.s3-us-west-2.amazonaws.com/components/latest/index.html >>>>>>>>> >>>>>>>>> <https://camel-preview-1.s3-us-west-2.amazonaws.com/components/latest/index.html> >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> First on this (and the dataformat and language index pages) there’s >>>>>>>>> statistics and a table generated by the extension, and then the >>>>>>>>> pre-existing table for comparison. There are some glitches, but the >>>>>>>>> basic >>>>>>>>> idea should be evident. >>>>>>>>>>> >>>>>>>>>>> Some comments on the formatting: >>>>>>>>>>> >>>>>>>>>>> - it’s not possible to combine the xref and the artifact id into the >>>>>>>>> same column. I’d have to write a much more sophisticated report >>>>>>>>> generator, >>>>>>>>> and I don’t think that’s appropriate. On the other hand, I like >>>>>>>>> having >>>>>>>>> them separate; for one thing, the fact that it’s an artifact id is >>>>>>>>> labelled. >>>>>>>>>>> - It is possible to combine the deprecated and description columns. >>>>>>>>> The json>>adoc tool would do this. I’m not sure I like that idea. I >>>>>>>>> do >>>>>>>>> wonder if it would be useful to report “deprecated since” to give >>>>>>>>> people an >>>>>>>>> idea how much longer it might be around. I don’t know if this >>>>>>>>> information >>>>>>>>> is available. >>>>>>>>>>> >>>>>>>>>>> Other comments: >>>>>>>>>>> >>>>>>>>>>> - the languages generated table is not yet working. I haven’t found >>>>>>>>> the doc codegen for it, if any. >>>>>>>>>>> >>>>>>>>>>> - there are some blank rows. I think these might be from >>>>>>>>> “miscellaneous” components: >>>>>>>>>>> >>>>>>>>>>> There are two tables on the “components” index page, one for >>>>>>>>> components and one for “miscellaneous components”. >>>>>>>>>>> >>>>>>>>>>> Earlier in automated codegen/processing these are treated >>>>>>>>> independently. >>>>>>>>>>> >>>>>>>>>>> What’s the difference? Is the any relationship between them? Is >>>>>>>>>>> there >>>>>>>>> any reason to have them listed on the same page? >>>>>>>>>>> >>>>>>>>>>> - I’d suggest to split these into two pages. >>>>>>>>>>> >>>>>>>>>>> - The extension is capable of generating the indexes in the nav >>>>>>>>>>> files, >>>>>>>>> but that requires Allow asciidoctor extensions when processing nav >>>>>>>>> files < >>>>>>>>> https://gitlab.com/antora/antora/-/issues/592 >>>>>>>>> <https://gitlab.com/antora/antora/-/issues/592>> which I think is >>>>>>>>> unlikely >>>>>>>>> to get into Antora 2.3. >>>>>>>>>>> >>>>>>>>>>> ——————— >>>>>>>>>>> >>>>>>>>>>> Here’s an example of a component .adoc header: >>>>>>>>>>> >>>>>>>>>>> [[activemq-component]] >>>>>>>>>>> = ActiveMQ Component >>>>>>>>>>> :page-source: >>>>>>>>> components/camel-activemq/src/main/docs/activemq-component.adoc >>>>>>>>>>> :artifactId: camel-activemq >>>>>>>>>>> :description: The activemq component allows messages to be sent to >>>>>>>>>>> (or >>>>>>>>> consumed from) Apache ActiveMQ. This component extends the Camel JMS >>>>>>>>> component. >>>>>>>>>>> :since: 1.0 >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Here’s what the component table generation looks like in the >>>>>>>>> components index.adoc: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Number of Components: indexCount:[] in >>>>>>>>> indexUniqueCount:[unique=artifactid] JAR artifacts >>>>>>>>> (indexCount:[attributes=deprecated] deprecated) >>>>>>>>>>> >>>>>>>>>>> [width="100%",cols="4,3,1,2,5",options="header"] >>>>>>>>>>> |=== >>>>>>>>>>> | Data Format | Artifact | Since | Deprecated | Description >>>>>>>>>>> |=== >>>>>>>>>>> indexTable::[cells="$xref,artifactid,since,deprecated,description”] >>>>>>>>>>> >>>>>>>>>>> Thoughts? >>>>>>>>>>> thanks >>>>>>>>>>> David Jencks >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> Zoran Regvart >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Claus Ibsen >>>>>>>>> ----------------- >>>>>>>>> http://davsclaus.com <http://davsclaus.com/> @davsclaus >>>>>>>>> Camel in Action 2: https://www.manning.com/ibsen2 >>>>>>>>> <https://www.manning.com/ibsen2> >>>>>>>>> >>>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> Claus Ibsen >>>>> ----------------- >>>>> http://davsclaus.com <http://davsclaus.com/> <http://davsclaus.com/ >>>>> <http://davsclaus.com/>> @davsclaus >>>>> Camel in Action 2: https://www.manning.com/ibsen2 >>>>> <https://www.manning.com/ibsen2> <https://www.manning.com/ibsen2 >>>>> <https://www.manning.com/ibsen2>> >>> >>> >>> >>> -- >>> Claus Ibsen >>> ----------------- >>> http://davsclaus.com <http://davsclaus.com/> @davsclaus >>> Camel in Action 2: https://www.manning.com/ibsen2 >>> <https://www.manning.com/ibsen2>
