+1, this is actually what is done by most static generators since some years so would be great to get it back in our ecosystem if possible. +1 to use asciidoc as the pivot format since this one is spec-ed (vs md or others which are less spec-ed until you go with latex/docbook).
Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <https://rmannibucau.metawerx.net/> | Old Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book <https://www.packtpub.com/application-development/java-ee-8-high-performance> Le jeu. 17 nov. 2022 à 13:25, Tamás Cservenák <[email protected]> a écrit : > Howdy, > > It's not about losing at all, on the contrary: my "proposal" would be to > keep reporting, but make them write in "intermediate" format, like for > example Markdown is (or Asciidoc). > Those formats are human readable, unlike APT/FML/XDOC etc. > > To me it would look like a win-win: > - you can still read the reports (those rendered in "intermediate" format, > as Javadoc and some others may be fully rendered in HTML) > - but savvy site owners could use whatever flashy skin, design and site > generator they want. > > That's all. > T > T > > On Thu, Nov 17, 2022 at 1:20 PM Gary Gregory <[email protected]> > wrote: > > > I really like that Maven provides the option to build a site, no matter > > what technological relics it uses. > > > > I do see two site use cases that are worth teasing out: > > > > I want to build and publish a site for public consumption. > > > > I want a local folder full of HTML reports for my review as a developer. > > For example, JaCoCo, PMD, SpotBugs, Checkstyle. Yes, I could look at the > > raw output from each plugin and I do that as well. If that raw output, > > usually XML is human readable enough, I might not need the HTML. > > > > All of this to say that there is still value in the whole stack IMO and > it > > would be a shame to lose it. > > > > Gary > > > > On Wed, Nov 16, 2022, 18:14 Tamás Cservenák <[email protected]> wrote: > > > > > Howdy, > > > > > > So, here is "stage No1" that pretty much already delivers what existing > > > site had: > > > https://github.com/jaxen-xpath/jaxen/pull/145 > > > > > > Point is: before, it was two runs to build and site (and took a total > of > > 2 > > > minutes), while now it is 10 seconds more than "build artifacts" (35 > > sec). > > > > > > To build it: mvn clean install -P site > > > > > > Just to clear up: I am NOT promoting JBake nor any other static site > > > generator, this was just an exercise to see if we can do simple maven > > sites > > > without site plugin. > > > > > > HTH > > > T > > > > > > On Wed, Nov 16, 2022 at 7:28 PM Tamás Cservenák <[email protected]> > > > wrote: > > > > > > > Howdy, > > > > > > > > I am pretty much convinced it can do all that site is able to do. > > > > Let's see the jaxen conversion result once done. > > > > > > > > Also, this would not push anything, I always wrote (at least intended > > to) > > > > "static site tool is left at discretion of user", I just mentioned > > JBake > > > as > > > > something that can buy out functionality of the maven-site-plugin, > > that's > > > > all. > > > > > > > > T > > > > > > > > On Wed, Nov 16, 2022 at 7:25 PM Benjamin Marwell < > [email protected]> > > > > wrote: > > > > > > > >> 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] > > > >> > > > >> > > > > > >
