+1 for the change, we need a static site generator, that has some community support!
(and another +1 for Asciidoc support, we have a few custom Velocity macros that do things like create "Info" quote blocks which Asciidoc supports directly) Some other thoughts: Minimizing system dependencies (complexity) would be great too, Hugo for example is a single binary, but Jekyll requires Ruby + Gems, and all of the JS frameworks require node + NPM. A JS build system often creeps into these projects anyway, so you end up with the static site generator and a JS toolchain, in those cases I'd favor the simplicity of a single JS based tool (instead of something like Jekyll and Node dep) That said, the Shiro site doesn't have much JavaScript, so this probably isn't a concern. The next thing to consider is our community's skill set, which is obviously skewed to Java :D, so if the tool we pick up requires a lot of custom code (for whatever reason), it might be easier to maintain in the long run if it were Java-based. (Though, ideally, we would avoid using a lot of custom code to generate the site). The current site has some custom logic to: * Display "Tips", "Info", "Warning" notes * The "Edit this page" on GitHub links * dependency tabs (show Maven or Gradle code blocks) * The download page table generation. The download page is the most complicated of this group, and IMHO would benefit from being simplified. Another thing to consider is `asf.yaml` supports Jekyll and Pelican (but we could also create a CI script to publish generated site to the CDN, via git) https://cwiki.apache.org/confluence/display/INFRA/Git+-+.asf.yaml+features#Git.asf.yamlfeatures-Staticwebsitecontentgeneration Lots of thoughts, not a lot of suggestions on moving forward, sorry. Of the three listed, I only have experience with Hugo, and that's been positive. I've also worked on a few Jekyll sites, some were great, others were painful. Does anyone have any strong feelings for or against any of these tools? On Mon, Aug 30, 2021 at 7:48 AM Benjamin Marwell <[email protected]> wrote: > Some of my own thoughts: > > while hugo is popular, I see some advantages in jbake: > > * it is Java based, so we can easily debug it if necessary > * it supports freemarker and asciidoc ootb, while hugo needs a > separate asciidoc installation > * jbake is also available via sdkman, which most of us use already. > > On the other hand: > > * probably short support tracks with yupiik minisite. > * maven plugin, so we don't even need sdkman if you don't have it already. > > -- > Ben > > Am Mo., 30. Aug. 2021 um 13:44 Uhr schrieb Benjamin Marwell > <[email protected]>: > > > > Hello everyone! > > > > Every now and then we have a discussion about replacing the scms site > > generator which we currently use with something more popular. > > > > There are three tools which came to our minds so far: > > * hugo [1] > > * jbake [2] > > * yupiik minisite [3] > > > > "hugo" is by far the most popular one next to jekyll. jbake is > > java-based, yupiik minisite is a tool by yupiik, the company Francois > > and Romain lead / work for. > > > > Please reply with your opinions about the tools or any arguments > > against a tool switch if you see the necessity to stay with scms. > > > > Ben > > > > [1] https://gohugo.io/ > > [2] https://jbake.org/ > > [3] https://github.com/yupiik/tools-maven-plugin >
