Just chiming in here: As the person who wrote SCMS for our needs (because the communication around this process in the early days at Apache was abysmal and it was just easier to write our own), I would strongly consider choosing the static site generator with the largest community and the most features. Not once, in all the years that we've been using SCMS, has anyone on the team or in the wider Shiro community asked to modify behavior, debug it, or add functionality.
Based on this, having a Java tool IMO is far less important (because honestly, no one is realistically going to be debugging or adding features) than using a stable, feature-rich tool with a massive community of supporters. I think we as a team will find so much more value in said tool/community than choosing a Java-based one. Hugo is a big plus from me - it's got great support, is super fast, and doesn't require the plethora of Ruby or NPM dependencies the others do. That's not to say we shouldn't use those others - IMO the best tool/community should 'win' here, I'm just stating my personal experience with many of these in my professional life. That's my .02 - HTH ;) Cheers, Les On Mon, Aug 30, 2021 at 12:19 PM Benjamin Marwell <bmarw...@apache.org> wrote: > 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 >
