With both the CI build for my PR and locally, `yarn build-all` is building the UI after the main build command. Obviously this doesn’t work.
Can someone point to a situation in which the UI is built before it is used? Any ideas why yarn is picking this dysfunctional workspace build order? David Jencks > On Aug 30, 2021, at 1:23 AM, Claus Ibsen <claus.ib...@gmail.com> wrote: > > On Sun, Aug 29, 2021 at 10:20 AM David Jencks <david.a.jen...@gmail.com > <mailto:david.a.jen...@gmail.com>> wrote: >> >> The current source state is now visible. >> >> - I npm-published my asciidoctor-jsonpath extension >> - The site content changes are at https://github.com/djencks/camel.git >> jsonpath-options branch. I’ve put all the generated changes as the last >> commit, so it should be possible to update the branch by dropping the last >> commit, rebasing on main, and regenerating the source with the maven build. >> - The camel-website changes are at >> https://github.com/djencks/camel-website.git issue-16854-jsonpath-options >> branch >> >> There’s a PR https://github.com/apache/camel-website/pull/614. >> >> I don’t understand what the patch-sitemap.js does and was having dependency >> problems so removed it from the command line. What does it do and why? >> >> The PR’s build fails because of missing ui bundle. Is this expected? I >> like to have the built UI bundle available somewhere: I often check in the >> built bundle. Locally I can’t build the UI, it complains somehow about the >> helpers for component sorting/hiding. >> >> I set up the build to fail on warnings, and there are quite a few warnings. >> >> There are several source problems I don’t know the proper fix for as it >> requires domain knowledge. One is these warnings: >> >> [00:47:14.821] WARN (asciidoctor): skipping reference to missing attribute: >> apisyntax >> file: >> docs/components/modules/ROOT/pages/google-calendar-stream-component.adoc >> source: https://github.com/djencks/camel.git (refname: jsonpath-options, >> start path: docs/components) >> [00:47:15.979] WARN (asciidoctor): skipping reference to missing attribute: >> apisyntax >> file: docs/components/modules/ROOT/pages/google-mail-stream-component.adoc >> source: https://github.com/djencks/camel.git (refname: jsonpath-options, >> start path: docs/components) >> [00:47:16.442] WARN (asciidoctor): skipping reference to missing attribute: >> apisyntax >> file: >> docs/components/modules/ROOT/pages/google-sheets-stream-component.adoc >> source: https://github.com/djencks/camel.git (refname: jsonpath-options, >> start path: docs/components) >> >> >> These three components are missing an apisyntax entry in their json files. >> The problem shows up in the current site as the literal string ’null’. >> > > Ah yeah it looks like the -stream components are not API based, I am > going to fix this for Camel 3.12. > > >> There are some inconsistencies and mysteries in the gulpfile.js. I’ve >> commented on some. >> >> It would be great to know if anyone else can build the site from the PR >> branch. >> >> David Jencks >> >>> On Aug 23, 2021, at 6:00 AM, Claus Ibsen <claus.ib...@gmail.com> wrote: >>> >>> Hi >>> >>> Ah yeah those were an idea to include the full page documentation in >>> case tooling may be able to use that for something useable. >>> However the tooling uses all the other bits, so we have just marked >>> those apis as deprecated. >>> >>> So we can remove the files from the camel-catalog. >>> I have created a ticket to remove them >>> https://issues.apache.org/jira/browse/CAMEL-16881 >>> >>> On Sun, Aug 22, 2021 at 9:48 AM Zoran Regvart <zo...@regvart.com> wrote: >>>> >>>> Hi David, >>>> >>>> On Sat, Aug 21, 2021 at 10:10 PM David Jencks <david.a.jen...@gmail.com> >>>> wrote: >>>>> >>>>> 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? >>>> >>>> I think the catalog contains those so that an alternative UI can show >>>> them, think tooltips or inline help in an IDE. I think, though I'm not >>>> 100% sure that VSCode tooling is using that... >>>> >>>>> 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. >>>> >>>> I'd keep it as simple as it can be, so plain .adoc files, or if we >>>> find out they're not used just remove them... >>>> >>>> 2c >>>> >>>> zoran >>>> -- >>>> Zoran Regvart >>> >>> >>> >>> -- >>> Claus Ibsen >>> ----------------- >>> http://davsclaus.com @davsclaus >>> Camel in Action 2: 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>
