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
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
Le mardi 22 novembre 2022, 00:20:00 CET Olivier Lamy a écrit :
> On Sat, 19 Nov 2022 at 09:08, Hervé Boutemy 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 moder
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
t
On Sat, 19 Nov 2022 at 09:08, Hervé Boutemy 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 "
it looks like one key issue you're facing is specific to
https://maven.apache.org site, = our own site that is:
1. an aggregation of near 100 subsites representing each one Maven subproject
(see https://maven.apache.org/scm.html#maven-sources-overview)
2. that uses Apache infra's svnpubsub engine
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
+1000
this evaluation is much more fair
it does not mean that looking at rearchitecturing a new site generation would
not be useful
key is
> I like some parts of this. I don't agree with others.
I suppose the good ideas from the Wiki should be prototyped:
- on a basic mono-module project
- on
Hi,
some my thoughts
- site looks can be changed be skins - so can be more modern
- long time on build site is caused by multiple executing the same Maven
phase for many reports [1]
- some reports, like tests result, static code analize is not usable for
static documentation - such reports should
There are a couple of things I would like to mention:
* the current output format of HTML is immediately usable, which is great
* any other format (md, asciidoc) is NOT and requires more tools to make
them consumable
* reporting into an additional format like asciidoc will require some
post
On Thu, Nov 17, 2022 at 7:20 AM Tamás Cservenák wrote:
>
> Howdy,
>
> Yes, that's right, the "bootstrap" effort is not the same, true.
>
That's a good way of putting it. I care a lot more about the
bootstrap effort (performed manually by people) than build time, where
I can go get a cup of coffe
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
+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
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
Howdy,
Yes, that's right, the "bootstrap" effort is not the same, true.
But otherwise, for example build execution time wise (this minimal project
site:site for me runs almost 2 minute, plus artifact build and testing is
about 26 sec = 2+ minutes) does a lot: it has everything in one pass
(artifa
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.
F
Thanks for demo'ing. What this shows me is that the initial effort to
create a site in this fashion is vastly greater than with the
maven-site-plugin. A lot of content that maven-site generates by
default has to be manually created to make it work with a static site
generator. For my workflow, the
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
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 ou
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.
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 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
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
23 matches
Mail list logo
