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.
--
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.
>>
>

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.
>>>
>>

I would also caution about Maven 3 because some organizations might
not have approved it for use while maven 2 has been approved. Using
maven 3 would reduce the 'audience' for the software.

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.

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...
--
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.
> >>>
> >>
>

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.
>> >>>
>> >>
>>

IMO, given that only developers really need to build Accumulo, it
doesn't seem like a big issue to require Maven3.

On 11/20/12 2:16 PM, David Medinets wrote:
> I would also caution about Maven 3 because some organizations might
> not have approved it for use while maven 2 has been approved. Using
> maven 3 would reduce the 'audience' for the software.

I won't pursue this issue, I just wanted to raise the concern.

On Tue, Nov 20, 2012 at 2:59 PM, Josh Elser <[EMAIL PROTECTED]> wrote:
> IMO, given that only developers really need to build Accumulo, it doesn't
> seem like a big issue to require Maven3.
>
> On 11/20/12 2:16 PM, David Medinets wrote:
>>
>> I would also caution about Maven 3 because some organizations might
>> not have approved it for use while maven 2 has been approved. Using
>> maven 3 would reduce the 'audience' for the software.
>
>

Don't take my comment as shooting you down, but more as me raising my
opinion of dissent. I don't want my lack of stated opinion to be taken
as agreeing with your opinion; so, I stated opinion. :)

If there are concerns/reasons which exist about only being compatible
with >=maven-3.0, I encourage them to be brought up and the community
can decide whether or not they are of greater concern. However, none
that have been raised so far hold enough weight to concern me.

On 11/20/2012 3:48 PM, David Medinets wrote:
> I won't pursue this issue, I just wanted to raise the concern.
>
> On Tue, Nov 20, 2012 at 2:59 PM, Josh Elser <[EMAIL PROTECTED]> wrote:
>> IMO, given that only developers really need to build Accumulo, it doesn't
>> seem like a big issue to require Maven3.
>>
>> On 11/20/12 2:16 PM, David Medinets wrote:
>>>
>>> I would also caution about Maven 3 because some organizations might
>>> not have approved it for use while maven 2 has been approved. Using
>>> maven 3 would reduce the 'audience' for the software.
>>
>>

Again a voice from the Maven sidelines:

Maven 2.x is becoming increasingly fossilized. The Maven PMC now plans
to release a 3.1 pretty soon. If anyone feels that there are people
marooned in a 2.x environment who must build the source, it would be
good to speak up.
On Tue, Nov 20, 2012 at 4:46 PM, Josh Elser <[EMAIL PROTECTED]> wrote:
> Don't take my comment as shooting you down, but more as me raising my
> opinion of dissent. I don't want my lack of stated opinion to be taken as
> agreeing with your opinion; so, I stated opinion. :)
>
> If there are concerns/reasons which exist about only being compatible with
>>=maven-3.0, I encourage them to be brought up and the community can decide
> whether or not they are of greater concern. However, none that have been
> raised so far hold enough weight to concern me.
>
>
> On 11/20/2012 3:48 PM, David Medinets wrote:
>>
>> I won't pursue this issue, I just wanted to raise the concern.
>>
>> On Tue, Nov 20, 2012 at 2:59 PM, Josh Elser <[EMAIL PROTECTED]> wrote:
>>>
>>> IMO, given that only developers really need to build Accumulo, it doesn't
>>> seem like a big issue to require Maven3.
>>>
>>> On 11/20/12 2:16 PM, David Medinets wrote:
>>>>
>>>>
>>>> I would also caution about Maven 3 because some organizations might
>>>> not have approved it for use while maven 2 has been approved. Using
>>>> maven 3 would reduce the 'audience' for the software.
>>>
>>>
>>>
>