Hi David Yeah its an improvement and thank for the core vs non-core components.
On Wed, Apr 15, 2020 at 11:37 PM David Jencks <david.a.jen...@gmail.com> wrote: > > 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> > -- Claus Ibsen ----------------- http://davsclaus.com @davsclaus Camel in Action 2: https://www.manning.com/ibsen2
