[MSHARED-480] Use maven-site-plugin's site.xml to use site's skin instead of default when run as mojo

[jira-importer]

Hervé Boutemy opened MSHARED-480 and commented

currently, when a reporting mojo is not used as maven-site-plugin's report but as direct mojo invocation, maven-site-renderer default skin is always used: would be more consistent if using site decoration consistently with maven-site-plugin
Or more precisely, I didn't currently find any reporting plugin that did the effort to mimic maven-site-plugin's decoration model/skin: every reporting plugin I know of uses features of maven-reporting-impl for site rendring (with this known limitation)

implementing the feature in maven-reporting-impl will make it accessible to any reporting plugin once it upgrades it dependency version

once done, we can activate skin resources copy, that was commented while working on MSHARED-120 (and would not give expected result if skin used is not consistent)

---

Affects: maven-reporting-impl 2.4

Attachments:

• screenshot-1.png (95.18 kB)
• screenshot-2.png (89.53 kB)
• screenshot-3.png (110.97 kB)
• screenshot-4.png (90.82 kB)

Issue Links:

• MSHARED-1168 Add support for markup output

• MSITE-690 Add new "process-reports" goal

Remote Links:

• GitHub Pull Request #15
  

[jira-importer]

Michael Osipov commented

I had the very same idea recently. I am not very pleased about SiteContext#templateName nor about the default-site.vm and its resources in DefaultSiteRenderer. I do believe that skin-related must be in the default skin and used through decoration model only. Of course, common stuff like the GIFs are OK to be as default resources in Doxia Site Renderer. Shouldn't we create another issue with DOXIASITETOOLS?

[jira-importer]

Hervé Boutemy commented

I do believe that skin-related must be in the default skin and used through decoration model only
I don't understand this

the current issue is currently against maven-reporting-impl that has to mimic maven-site-plugin's decoration model handling in the context of direct mojo invocation, and that currently was just implemented in a basic way.

With the rework done for Doxia Sitetools 1.7 API, I think it's time to improve maven-reporting-impl

And once maven-site-plugin's skin is used for the template part, resources are not an issue: it is natural to address resources in the same work

[jira-importer]

Michael Osipov commented

Let me rephase the statement you did not understand: A skin has to be complete, i.e., all necessary resources have to be available in its JAR. For the Default Skin, it isn't the case because the Site Renderer has its site.vm called default-site.vm which is bad. Your last statement pretty much resembles my statement but expressed differently.

By direct mojo invocation your mean like mvn project-info-reports:dependencies? If yes, I do agree that shouldn't be any different than having the report configured with mvn site.

[jira-importer]

Hervé Boutemy commented

For the Default Skin, it isn't the case
wrong, images are also in doxia-site-renderer jar file

the fact that the name of the template and the way resources are foudn is not exactly the same for default and for a skin is not important: the algorithm is coded in doxia-site-renderer

By direct mojo invocation your mean like mvn project-info-reports:dependencies?
yes, exactly

and yes, the result should not be different: if it's not currently, that's simply because it's harder to do
and it was even harder at the beginning, when most of the site rendering algorithm was in maven-site-plugin: but now that most of the algorithm is in doxia-site-renderer, it should be easier to use it in maven-reporting-impl

[jira-importer]

Michael Osipov commented

Hervé Boutemy, I think we have agreed and will burry this idea. WDYT?

[jira-importer]

Hervé Boutemy commented

yes, let's stop trying to make a standalone report mojo look like if it was done part of a site: standalone is standalone
having a standalone-oriented output will clarify many things, and finally improve user experience

in fact, this issue should be superceeded by another defining the standalone report look and feel

[jira-importer]

Michael Osipov commented

Closing as won't fix.

[jira-importer]

Michael Osipov commented

Reopening for the moment since I found a non-too-intrusive way to solve this problem. Will share a possible solution next after Doxia Sitetools 2.0.0-M4 release.

[jira-importer]

Michael Osipov commented

Here is a solution to the issue:

1. Build from master...use-site.xml and install
2. Build from apache/maven-project-info-reports-plugin@doxia-2.0.0...use-site.xml and try

Hervé Boutemy, I am not fully happy with apache/maven-project-info-reports-plugin@doxia-2.0.0...use-site.xml#diff-7f69e35571e6f28056ef79ea1930349d407b4ccd405a2c75e45ba3e6e47a8430R188-R194, maybe you have a better idea for this test config snippet.

[jira-importer]

Michael Osipov commented

Here is a comparison from my project:
With Maven Site Plugin:
!screenshot-1.png!
Direct invocation after the fix:
!screenshot-2.png!

Don't mind the heading size, this needs to be fixed in Fluido. The menu is correct since the menu is also populated by the Maven Site Plugin sans the reports.
From my opion the menu on the side or top is useless:
!screenshot-3.png!

From Fluido Skin we need to internally set this:

34   <custom>
35     <fluidoSkin>
36       <topBarEnabled>false</topBarEnabled>
37       <sideBarEnabled>false</sideBarEnabled>
38     </fluidoSkin>
39   </custom>

and the result:
!screenshot-4.png!

Note: Now the context contains the information about standalone execution so we can distinguish.

[jira-importer]

Michael Osipov commented

Let me know what you think.

[jira-importer]

Hervé Boutemy commented

wow, i love the idea of disabling the menus: it now focuses only on the page content, without trying to mimic the integration in a full web site

with such change, it gives even more sense to markup output MSHARED-1168: this HTML output focused only on page content has the same meaning as the markup one

we definitely need to aggregate both features to have a great site-less reporting approach

[jira-importer]

Hervé Boutemy commented

another aspect that this now makes clear, and I was struggling to explain my feeling until now (I now see why...): on sections titles and the change to have Doxia section 1 rendered with h1 instead of h2 previously, which seemed crazy

Here, it proves why section 1 to HTML h2 was not crazy: as you can see, there is the title of the page ("Active DNS Locator" in your example) that is rendered in the header section of the HTML output (by the skin...)

i don't know of the skin renders the title as h1 or as another malrkup, but the (unsaid until now) reasoning of the historic choice of rendering section 1 to h2 was to have this title as h1 (in old skins, I suppose).

We'll need to discuss on that again, i suppose, now that I was able to clarify the historical reasoning...

definitely, this new rendering clarifies a lot the page content vs the site "decoration" from Doxia Siterenderer with its skins

[jira-importer]

Michael Osipov commented

Fixed with d2032091c1bd86c6f52d80a23852aff0e8c0b6ae.