Hi all! Thanks for your insights.
Sounds as if we should give jbake a try. If we encounter any issues during the transition, we can go back to the discussion. As for yupiik minisite, we could try that on an extension for shiro which is not maintained in the main repository. This way it might get more known and we can gain some experiences with minisite. I was thinking about how to set up a branch without losing too much (or any) history. The new branch should probably be branched off the main branch with no modifications except a jbake init, and then convert everything step by step. There has been a conversion of an html5up template using freemarker: https://github.com/manikmagar/jbake-future-imperfect-template Maybe this is something to start with? It was recommended to me in the jbake gitter channel. The recommendation about the template engine is: "Use what you know best." I would like to add IDE support to that equation :) freemwarker is a good choice imo (I personally know it a bit and it is run by the ASF and in active development), but others will also do. -- Ben Am Mo., 30. Aug. 2021 um 17:49 Uhr schrieb Francois Papon <francois.pa...@openobject.fr>: > > Hi, > > We definitively agree that we need a new site generator! > > If we want to stay in java community, so may be JBake is the best choice. > > I would like to propose yupiik minisite but as a new fresh project, the > community is not big enough yet. > > so +1 for JBake. > > regards, > > François > fpa...@apache.org > > Le 30/08/2021 à 17:40, Brian Demers a écrit : > > +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 <bmarw...@apache.org> > > 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 > >> <bmarw...@apache.org>: > >>> 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
