great news: I just created a proof of concept where reporting can output markup instead of a html site
please review https://github.com/apache/maven-reporting-impl/pull/13 the added IT shows the feature tested by running report as a direct goal invocation, with output format as xdoc or apt as they are currently the only markup formats with Sink implementation, but it could work with any other just upgrading maven-reporting-impl in any reporting plugin, like maven- project-info-reports-plugin or maven-plugin-plugin can show the feature in interesting real world plugins of course, with a Markdown sink implementation, this will give more interest to the feature... Le mardi 22 novembre 2022, 09:04:21 CET Hervé Boutemy a écrit : > yes, using a nowadays de-facto standard Markup language like asciidoc or > Markdown as a pivot is one the the good ideas from this discussion > > and I feel it could be a concrete step implemented independently, going in > the right direction without being disruptive, that could open tests for > tests on next steps = trying to change the rendering steps (currently > implemented in Doxia Sitetools + associated skins) > > implementation ideas: > given many reports are implemented using Doxia Sink API to describe the > generated content, generating the markup instead of direct Maven site html > is just about injecting a Sink implementation > > Sadly, Markdown and Asciidoc are the 2 markups where there is no Sink > implementation available yet > https://maven.apache.org/doxia/references/index.html > - for markdown, issue is there waiting for implementation > https://issues.apache.org/jira/projects/DOXIA/issues/DOXIA-569 > - for AsciiDoc, equivalent is necessary > > Once we have a Sink implementation available, injecting it for any plugin > could be done in Maven Site Plugin I suppose, or even in > maven-reporting-impl for direct goal invocation -- i.e. "mvn > project-info-reports:index" (probably with a "-DoutputFormat=adoc") could > generate a .md or .adoc instead of generating .html > > it looks really feasible... > > Le mardi 22 novembre 2022, 08:04:18 CET Romain Manni-Bucau a écrit : > > Well, think the point of a pivot format (adoc) is mainly the composability > > and reusability. With doxia we are very far even if it can be sexy > > (theme). > > The other fact is the adoption of the technology - whatever its quality. > > Doxia is a maven solution at the end, adoc (or md strictly speaking) is a > > tech guys + writers solution so it covers multiple languages but also > > people so solutions are way wider. > > So being able to render anything in this pivot format then convert it or > > not to html sounds like a move forward to me - but also agree people > > already do it so it is mainly a question for maven to get it as a first > > citizen feature or not IMHO. > > > > 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-performan > > ce> > > Le mar. 22 nov. 2022 à 00:20, Olivier Lamy <[email protected]> a écrit : > > > On Sat, 19 Nov 2022 at 09:08, Hervé Boutemy <[email protected]> wrote: > > > > Le vendredi 18 novembre 2022, 07:57:59 CET Slawomir Jaranowski a écrit : > > > > > Hi, > > > > > > > > > > some my thoughts > > > > > - site looks can be changed be skins - so can be more modern > > > > > > > > yes > > > > it seems people don't understand the menu generation with it's > > > > > > "decoration > > > > > > > model", then we don't see many people doing more skins > > > > > > there are still some (more modern than the one we are using...) > > > look here https://devacfr.github.io/reflow-maven-skin/ > > > I forked one here https://github.com/olamy/reflow-maven-skin to make > > > it work with a recent version of doxia. > > > > > > > Having graphic people being able to do skins would be awesome, that's > > > > > > one of > > > > > > > the benefits I see in Tamas proposal: I still need to understand how > > > > the > > > > > > other > > > > > > > static generation tools manage the menu creation and overall > > > > > > "decoration" of > > > > > > > the main content of a page > > > > > > > > > - long time on build site is caused by multiple executing the same > > > > > > Maven > > > > > > > > phase for many reports [1] > > > > > > > > true > > > > thinking at "why": because the maven-site-plugin does the report goals > > > > invocation, it's not Maven core > > > > that's one of the reasons why I love Tamas idea about having Maven > > > > > > generate > > > > > > > "*-reports.jar" then the new site rending process just rendering to > > > > HTML > > > > > > > > I don't like some words of Tamas on the topic, but there are also very > > > > > > good > > > > > > > ideas that could halp a better new site generation architecture :) > > > > > > > > > - some reports, like tests result, static code analize is not usable > > > > > > for > > > > > > > > static documentation - such reports should be generated by CI > > > > > nowadays > > > > > > > > as you know, I disagree: it is usable for some use cases, which are > > > > not > > > > > > the > > > > > > > use cases you are interested in > > > > > > > > > [1] https://issues.apache.org/jira/browse/MSHARED-1044 > > > > > > > > > > śr., 16 lis 2022 o 11:19 Tamás Cservenák <[email protected]> > > > > > > napisał(a): > > > > > > 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 > > > > > > > > --------------------------------------------------------------------- > > > > 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] > > --------------------------------------------------------------------- > 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]
