Maven 2.x and 3.x Site Plugin

This might be related to MNG-1855 but it has been raised for checkstyle-plugin module. It's true for other plugins as well.

not really related to mng-1855

this is a design issue... do we need a reportingManagement element?

Is there a way to make site reporting honor plugin config in <build/>?

We can have a <reportingManagement/> element to config reporting as such.
But then we would land up in a situation where certain configurations have to be repeated in <pluginManagement/> as well as <reportingManagement/>.

The solution would serve the purpose but won't be as elegent

It's intentionally the other way around.

settings in reporting are already applied to build plugins so they don't need to be duplicated, but build plugins have a more honerous requirement - specifically they will often fail the build when the reporting plugin won't during site generation. For this reason, build configuration is not passed to the reports.

Wonderful!

So the <reportingManagement/> idea in action_53690 actually makes sense to me now and appears clean enough too.

This also appears to be a candidate for docu. somewhere (maybe in maven-model) specifying the distinction between <build><pluginManagement/></build> and <reportingManagement/> and what should go where (as part of best-practice).

Any thoughts re moving this up the priority ladder? After all one of the key benefits of using maven is the reduction in duplicated configs and currently I am not able to share any of my reporting settings across projects.

Additionally re reporting plugin configs affecting build plugin settings.

I uses a number of plugins for both reporting and compliance/governance checks, currently javadoc warnings, pmd, checkstyle and test coverage. I would like to be able to run reporting against one set of configs and have build uses others. Ie. reporting tends to use quite a harsh set of rules for PMD/Checkstyle whereas my compliance build (which fails the build if a governance setting is not met) uses a more relxed config. How can i achieve this separation on configs for plugins that are used in both reporting and build?

this is as high up the priority ladder as it goes. no pom additions until 2.1, sorry.

In relation with MNG-1855:

when using a report plugin needing a dependency (
checkstyle, set as in:
http://maven.apache.org/plugins/maven-checkstyle-plugin/tips.html, ont sure this example is working, but no time to test it, sorry.)

extra jars need to be added to classpath. It's not possible right now, cause report part has no dependencies child.

Maybe plan to add this to reportManagement?

It would be nice to be able to add custom taglets to a classpath used just for reporting, for instance

Quite painful in combination with MJAVADOC-268, where it's needed to be able to force a version.

Now the site plugin's use case.

Jason,

If this the issue of moving all reporting plugins configuration into the Site Plugin? Is this a requirement for Maven 3? Would it be possible to make this work for Maven 2.1+ as well?

I want to add an idea how to solve this issue. It could be done by offering a new boolean property in the reporting section like "honorPluginManagement". Default should be false, but if it is set to true, the plugins in the reporting section would use the respective configurations in pluginManagement. It should then also be possible to override pluginManagement settings in the reporting section. Moreover, it should work no matter if the reporting section is in the same pom as the pluginManagement section, or if it is further down the inheritance tree. At least from my current personal perspective, this would be a good solution.

I can see however that some people may want a separate pluginManagement-like section within the reporting section.

I like Sven's idea. Ultimately, I am looking for a way to say, "Use javadoc 2.8" once – this should affect both the <build> and <reporting> sections, otherwise my pom violates the DRY principle.