Home | About | Sematext search-lucene.com search-hadoop.com
 Search Hadoop and all its subprojects:

Switch to Threaded View
Accumulo, mail # dev - Re: If you are wondering why site:site seems to take about a week ...


Copy link to this message
-
Re: If you are wondering why site:site seems to take about a week ...
Benson Margulies 2012-11-20, 19:22
On Tue, Nov 20, 2012 at 2:16 PM, Christopher Tubbs <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>wrote:
>
>> On Tue, Nov 20, 2012 at 2:03 PM, Christopher Tubbs <[EMAIL PROTECTED]>
>> 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 <[EMAIL PROTECTED]>
>> 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.
>> >>>
>> >>
>>