Home | About | Sematext search-lucene.com search-hadoop.com
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB
 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 ...
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.
>> >>>
>> >>
>>
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB