On Tue, Nov 20, 2012 at 2:16 PM, Christopher Tubbs <ctubb...@gmail.com> wrote: > That's interesting... because I was under the impression that the reporting > section is simply translated internally to configuration passed to the > maven-site-plugin. If this is not the case, I need to learn some more. > However, if it is the case, then, it seems more natural to not rely on the > correct translation of the reporting section to plugin configuration, and > just configure that plugin explicitly.
First, there are issues of configuration inheritance. When a child pom inherits <reporting> configuration from a parent pom, there is an orderly process of merging them. If you do it all in the <plugin/> element of the site plugin, there is no orderly process. Then we've got the problem of forked executions causing very slow site builds. One of my fellow-committers on Maven offered the opinion that this problem was *also* exacerbated by the new style of config. I don't have any details as to why, and he might be wrong, and I might have misread him. > > Perhaps I've misunderstood you. Were you suggesting ignoring the site build > entirely, as we're not really using it to generate a site, and just using > the various independent reporting tools to generate javadoc artifacts, code > coverage reports for Jenkins, etc., and avoid doing any site building > whatsoever? Because, I've heard that recommendation before also... I'm not suggesting punting on the use of the site, I like Maven sites. The model I am deriving, however, is that some features of Maven sites just don't work too well. In particular, any reporting mojo that declares a forked execution is deadly in any project large than tiny. > > > -- > Christopher L Tubbs II > http://gravatar.com/ctubbsii > > > On Tue, Nov 20, 2012 at 2:05 PM, Benson Margulies > <bimargul...@gmail.com>wrote: > >> On Tue, Nov 20, 2012 at 2:03 PM, Christopher Tubbs <ctubb...@gmail.com> >> wrote: >> > Moving to the natural Maven 3 usage of maven-site-plugin as a normal >> build >> > plugin, with configuration for reporting, instead of dealing with the >> > massive "reporting" section that gets mapped to the maven-site-plugin, >> may >> > also help. >> >> >> Just the opposite. As a member of the Maven PMC, I can sadly report >> that we currently recommend *against* that. It was not thought >> through, it doesn't work very well, and in particular it makes this >> problem worse. >> >> >> > >> > >> > -- >> > Christopher L Tubbs II >> > http://gravatar.com/ctubbsii >> > >> > >> > On Sun, Nov 18, 2012 at 6:46 PM, Josh Elser <josh.el...@gmail.com> >> wrote: >> > >> >> +1 For moving cobertura to its own profile, add something saying so to >> the >> >> readme/website, and let people decide when they want to activate it. >> >> >> >> >> >> On 11/18/2012 05:56 PM, Benson Margulies wrote: >> >> >> >>> There's a very longstanding bug/confusion in Maven that results from >> >>> reporting plugins that fork executions. That's not the same thing as >> >>> forking a jvm, it's an internal maven business where a plugin says, >> >>> 'whoops, to run me you have to make a whole new maven and run all this >> >>> other stuff first'. >> >>> >> >>> The cobertura plugin does this. So does Javadoc in some really >> irritating >> >>> cases. >> >>> >> >>> If folks would like a faster site build, I'd suggest moving cobertura >> >>> to a profile. >> >>> >> >>> If the current 'go for coffee' situation doesn't bother anyone too >> >>> much, we can leave it alone. >> >>> >> >> >>
