I have a question about the purpose of the .adoc files in the catalog. The changes proposed here will remove the tables of options from these copies of the component .adoc files. These copies are already quite skimpy as they don’t successfully include the spring-boot information.
What are these copies of the .adoc files supposed to be useful for? If there’s a desire to make them more complete, one strategy would be to build the components module of the website using a custom UI that has nothing in it, so we just get plain undecorated html pages, and putting those in the catalog. It would require some investigation, but it might conceivably be possible to arrange so links out of the components module go to the website rather than just be broken. David Jencks > On Aug 17, 2021, at 5:04 PM, David Jencks <david.a.jen...@gmail.com> wrote: > > Hi Zoran, > >> On Aug 17, 2021, at 2:46 AM, Zoran Regvart <zo...@regvart.com >> <mailto:zo...@regvart.com>> wrote: >> >> Hi David >> >> On Tue, Aug 17, 2021 at 7:42 AM David Jencks <david.a.jen...@gmail.com >> <mailto:david.a.jen...@gmail.com>> wrote: >>> >>> I’ve made a lot of progress on this and put up a preview of the current >>> state. Only components in the latest branch are done (not dataformats, >>> eips, languages, other, and not other versions). >> >> Perhaps we can create (sub)issues for outstanding work so folk can >> jump in and help as well? > > The others look easy :-) but finding out if anyone else can configure the > extension might be useful:-) I don’t want to push the plugin code until I’ve > reviewed and documented it, and likely I’ll spend a few minutes doing the > others before I get done with those tasks. We’ll see. > >> >>> The arrangement of, in particular, API data didn’t make much sense to me so >>> I reorganized it so relevant information is all together, and added a lot >>> of in-page links. >> >> What sometimes bothered me is that I could not point someone to an >> exact option in the table, perhaps this is for another time but I >> think it would be good to have much more anchors within the page, one >> of those would be for each individual option. Perhaps as a follow up >> on this work. > > This is easy to do :-), it should be in the next preview. Perhaps because > they are links into a table, Asciidoctor doesn’t seem to get them into the > anchor catalog and can’t verify that the links are valid, so there are info > messages. However, the links appear to work fine. Info messages would only > occur for in-page links, which are somewhat unlikely. >> >>> There are a couple of glitches… >>> - “debugging code” showing e.g. "pascalcasescheme: Twilio” >> >> I'd assume this would be trivial to fix :) > > :-) >> >>> - For some reason lists don’t display properly in the first row of tables. >>> At >>> https://camel-preview-1.s3.us-west-2.amazonaws.com/components/latest/twilio-component.html#_path_parameters_2_parameters >>> compare the apiName row and the methodName row. >>> >>> https://camel-preview-1.s3.us-west-2.amazonaws.com/components/latest/twilio-component.html >>> is the most complex page, and can be compared to the current site at >>> https://camel.apache.org/components/latest/twilio-component.html. >> >> Yeah, we could also add the enum values inline, i.e. not in a list, >> perhaps within a <code> tag, not sure if it's worth spending too much >> of an effort on this. I'd create a follow up issue for this and any >> other cleanup tasks... > > I really like the list as opposed to listing the values in a sentence. It > might be a bug in asciidoctor or in my extension. In any case I don’t think > it’s a blocker. > >> >>> I haven’t published the updates needed to the Asciidoctor extension that >>> does the generation, so a PR is not yet feasible. >> >> Would love to see how this is shaping up, even if you have it >> somewhere in a draft phase it would be good to get familiar with the >> code. Perhaps we can create a branch on the camel-website and work on >> it from there? Would be easy (I think) to set up a preview via GitHub >> Workflow + Netlify or a Jenkins build and a staging site hosted by >> ASF... > > I think this is probably feasible once I push my changes to my jsonpath > Asciidoctor extension to gitlab, but I’m not quite ready to do that. I could > push the camel changes to a branch before that, but it wouldn’t be buildable. > >> >> I've noticed that the Kamelet catalog is not rendering correctly >> (https://camel-preview-1.s3.us-west-2.amazonaws.com/camel-kamelets/latest/index.html >> >> <https://camel-preview-1.s3.us-west-2.amazonaws.com/camel-kamelets/latest/index.html>), >> not sure if that's a CSS issue or it has something to do with the >> changes you're making. > > I’m not sure what’s going on with that! It looks quite amazingly out of > proportion!! I tried updating the ui and rebuilding and got worse problems > with the custom component ordering blowing up, and I haven’t been able to get > anything to work with yarn. Before worrying about the Kamelet catalog lets > get this in a state others can build. I doubt it’s anything I did, I think > it’s a problem of some sort with my copy of the camel UI. >> >> Thanks David for taking this on, looking forward to this, it should >> cut down a lot of the complexity in how we build the website and >> remove some of the work needed in the main camel repository. I can >> even see us not needing to do as many regen commits as an outcome of >> this! > > Yes, I think the only function of the UpdateReadmeMojo is going to be to set > the header attributes. We’ll see. > This does involve a lot of manipulation of javascript objects, and it may > well slow the website build down a bit. I implemented some caching so each > .json file is only read once per page, so I don’t think it’s likely to make > the build unusably slow. > >> >> zoran >> -- >> Zoran Regvart > > David Jencks
