Please do NOT consider jbake. We (shiro team) ported the page to jbake, and it is really a mess. Many things are not supported which can easily be done in other static site generators. There is absolutely no progress. No java.time support. JSON/YAML support is broken and needs a lot of workarounds.
Look at the repo and build it yourself -- the amount of javadoc will take very long to process. https://github.com/apache/shiro-site Am Mi., 16. Nov. 2022 um 13:21 Uhr schrieb Tamás Cservenák <[email protected]>: > > Howdy, > > I am pretty much sure your site could be pretty much "transported" to use > jbake-maven-plugin instead of maven-site-plugin. > > I am aware of the long history of the Maven project, being here since 2006, > but still... > I don't think what I propose is "build a lamborghini instead of a ford > pickup". > > I see it more like "let's replace the ford battery, but given how old it > is, we have > only aftermarket parts for it". > > Now that you have shown your site, let me try to de-site it, just as an > experiment... > as I never tried this before.... > > Will do it here > https://github.com/cstamas/jaxen > > Thanks > T > > On Wed, Nov 16, 2022 at 1:08 PM Elliotte Rusty Harold <[email protected]> > wrote: > > > I like some parts of this. I don't agree with others. I agree that > > maven site isn't competitive with other site builders, but that was > > never really its purpose. I think it's OK for generating a site for a > > Maven project. I wouldn't expect it to be used for anything else. As a > > maintainer of one such site <http://www.cafeconleche.org/jaxen/> it > > would be very inconvenient for me if this plugin disappeared or > > changed in a major way. > > > > The old site design just works. We don't need so-called modern, > > responsive sites. For our purposes — documenting code — the 20 year > > old classic HTML we use is just fine. In fact, I'd say it's superior > > to modern designs as implemented in practice. > > > > I do wish Maven hadn't gone its own way with NIH components like > > Plexus, APT, and Doxia that are all essentially used today by maven > > and no one else. However in fairness this all happened twenty years > > ago when alternatives that have become de facto standards was not > > obviously better or simply did not exist. We should modernize our > > dependencies where possible, but I don't think a rewrite is worth the > > effort and I would oppose anything that broke existing sites, links, > > and workflows. > > > > When counting "wasted engineering hours spent on it", these are at > > least a couple of orders of magnitude lower than would be spent on a > > radical replacement of the sort being proposed. It's like proposing we > > build a new Lamborghini to save the money we spend on oil changes for > > our 2002 Ford pickup. Of course this is open source, so if anyone has > > the time and money to spend on an alternative site plugin that > > scratches their itch, by all means they can do it. However this should > > be a new plugin projects can adopt or not at a time that's convenient > > for them. It should not replace the existing plugin so many projects > > already use. > > > > On Wed, Nov 16, 2022 at 5:19 AM Tamás Cservenák <[email protected]> > > wrote: > > > > > > Howdy, > > > > > > This is really just a brainstorming thread I'd like to spin, regarding > > > Maven Site stuff. > > > > > > Again, the message is in wiki > > > https://cwiki.apache.org/confluence/display/MAVEN/Quo+Vadis+Maven+Site > > > > > > But I would like to make discussion happen here on dev ML. > > > > > > Thanks > > > T > > > > > > > > -- > > Elliotte Rusty Harold > > [email protected] > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
