I think I’ve covered all the work related to this in a final PR, https://github.com/apache/camel/pull/6124. It was supposed to be simple but I discovered quite a few problems…
I suspect it would be fairly simple to back port these changes to 3.11.x. Shall I look into doing that? 3.7.x would probably be harder, but I could look into that also. 3.4.x is about to be removed so I won’t consider it, nor 2.x David Jencks > On Sep 13, 2021, at 9:05 AM, David Jencks <david.a.jen...@gmail.com> wrote: > > > >> On Sep 13, 2021, at 8:05 AM, Zoran Regvart <zo...@regvart.com> wrote: >> >> Hi Cameleers, >> some of these changes are in, and for the last one explicitly stated >> in the $subject I'll create a pull request soon. >> >> You will notice changes in the workflow and in the git repository. >> We're now using symbolic links and not copying files over to the docs >> directory, with the jsonpath macro, that's in the works now, the >> configuration tables will not be generated with the Maven plugin. >> >> So far we did not have major issues with this, with jsonpath macro >> change I do anticipate some issues as the assumption there is a >> one-to-one relationship between the .adoc file and the .json metadata >> file. And that is not true for some cases. Right now I'm thinking in >> those cases we keep the Maven plugin, but I have to see if that can be >> avoided. > > I thought I’d taken care of these, but I could easily have missed some. The > name of the json file for a component/dataformat/etc page is in the > `shortname` attribute so I think we can deal with these cases by setting that > attribute explicitly in the maven plugin when we write out the header. I > remember doing this explicitly for mail/imap/smtp/etc and I thought bindy > just worked. The bindy results look OK to me… > > One possibility for the future relates to the annotations docs that I think > are only in bindy at the moment. Architecturally I don’t like having the > maven doc construction plugin scanning the source for annotations. I think it > would be more appropriate to move this scanning code to whatever is > constructing the json metadata file and put the results into the json file. > That’s definitely not part of this current effort :-) > > Thanks for all the work! It definitely makes sense to roll this out in the > small chunks you are creating, although that certainly wasn’t how I developed > it! Having more eyes is wonderful :-) > > David Jencks > >> >> Anyhow, happy to hear comments on this and do reach out if you notice >> any faults on the website or issues in your workflow... >> >> zoran >> -- >> Zoran Regvart
