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 [email protected] 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 <[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
