Agreed, as if you run this "demo" PR, you will see that: - we have all these report goals usable, kinda - kinda usable as all they spit out rendered HTML in inconsistent way - as they run outside of site run, skins seems "randomly" (probably by deps) selected - and rendered HTML is not reusable at all
It could be done by pandoc to convert html back to markdown to let it pass through jbake, but that would complicate even more the -- IMHO really simple -- PR that is according to Eliott overly complicated. If we are able to extract information, why not make it in some reusable format then? T On Thu, Nov 17, 2022 at 1:27 PM Romain Manni-Bucau <rmannibu...@gmail.com> wrote: > +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 <ta...@cservenak.net> 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 <garydgreg...@gmail.com> > > 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 <ta...@cservenak.net> > 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 <ta...@cservenak.net > > > > > > 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 < > > bmarw...@apache.org> > > > > > 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 > > > > >> <ta...@cservenak.net>: > > > > >> > > > > > >> > 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 < > > > > >> elh...@ibiblio.org> > > > > >> > 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 < > > > > ta...@cservenak.net> > > > > >> > > 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 > > > > >> > > elh...@ibiblio.org > > > > >> > > > > > > >> > > > > > > --------------------------------------------------------------------- > > > > >> > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > > > >> > > For additional commands, e-mail: dev-h...@maven.apache.org > > > > >> > > > > > > >> > > > > > > >> > > > > >> > > --------------------------------------------------------------------- > > > > >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > > > >> For additional commands, e-mail: dev-h...@maven.apache.org > > > > >> > > > > >> > > > > > > > > > >
