Interesting point of view :) Thanks for your feedback Les, it's good to see you on the mailing list!
regards, François fpa...@apache.org francois.pa...@openobject.fr Le 30/08/2021 à 21:28, Les Hazlewood a écrit : > 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
