You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Benson Margulies <bi...@gmail.com> on 2012/11/18 23:24:14 UTC
Site plugin and forked executions
Folks,
I myself feel like a bit of a looping site build myself on this
subject, and I apologize.
The build of Apache Accumulo is showing the 'classic' symptoms of
running more or less forever with 'site:site', due, apparently, to
some forked execution that causes it to do the same things over and
over.
Is this really the intended behavior?
I'd like to help cure it, but I am still very much feeling an idiot
about the whole business.
--benson
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Site plugin and forked executions
Posted by Hervé BOUTEMY <he...@free.fr>.
Le mardi 27 novembre 2012 21:45:16 Benson Margulies a écrit :
> On Tue, Nov 27, 2012 at 8:48 PM, Hervé BOUTEMY <he...@free.fr>
wrote:
> > I had a second thought about aggregate reporting plugins (or more
> > precisely
> > goal).
> >
> > Since some time, we're applying a new pattern where there is a separate
> > reporting goal for aggregate (previously, aggregate was a parameter).
> > In the maven parent pom, we're explicitely setting a reportSet
> > configuration for m-javadoc-p, which is the first plugin implementing
> > this pattern IIRC. But for other plugins, we don't define reportSets:
> > then by default, every reporting goals are used, ie aggregate and
> > non-aggregate.
> >
> > Now I understand why I'm experiencing twice PMD or Checkstyle runs in
> > components lately...
>
> Now there's no use of the aggregate reportSet. If we wanted
> aggregation, how would we write it do happen in the right place?
you can look at Maven core's pom.xml, which defines aggregated reports for
javadoc
notice:
1. this pom actually defines "non-aggregate" reportSets, which duplicates the
"default" reportSets: I'm waiting for Git rw to remove them
2. aggregate reportSets are marked <inherit>false</inherit> to avoid being run
in child modules, which is a good practice to give to users
3. AFAIK, this is not well documented in m-site-p (is it even documented in
another place than pom descriptor [1]?): now that I think I understand well, I
should be able to write something, probably in [2] , but any help appreciated
Regards,
Hervé
[1] http://maven.apache.org/ref/3.1-SNAPSHOT/maven-
model/maven.html#class_reportSet
[2] http://maven.apache.org/plugins/maven-site-plugin/examples/configuring-
reports.html
>
> > I just created MPOM-39 for tracking this issue.
> >
> > Regards,
> >
> > Hervé
> >
> >
> > [1] https://issues.apache.org/jira/browse/MPOM-39
> >
> > Le lundi 19 novembre 2012 20:50:07 Dennis Lundberg a écrit :
> >> Hi
> >>
> >> Yes, most likely. There are a bunch of JIRAs for the Site Plugin about
> >> issues like the one you're experiencing. The two things that stands out
> >> from memory are:
> >>
> >> - aggregate reporting plugins (like Javadoc in your example)
> >> - using the "new" way of configuring reporting plugins, i.e. under the
> >> Site Plugin's configuration> element
> >>
> >> I try to stay away from both if I can...
> >>
> >> On 2012-11-19 14:31, Benson Margulies wrote:
> >> > Or is this the real villan:
> >> >
> >> > [DEBUG] Lifecycle site -> [pre-site, site, post-site, site-deploy]
> >> > [INFO]
> >> > [INFO] >>> maven-javadoc-plugin:2.9:aggregate (report:aggregate) @
> >> > accumulo >>> [INFO]
> >> > [INFO]
> >> >
> >> > [INFO] Forking accumulo 1.5.0-SNAPSHOT
> >> > [INFO]
> >> >
> >> > On Mon, Nov 19, 2012 at 8:30 AM, Benson Margulies
> >> > <bi...@gmail.com>
> >
> > wrote:
> >> >> Does the below show the enforcer plugin, of all things, forking?
> >> >>
> >> >> [DEBUG] Configuring mojo
> >> >> 'org.apache.maven.plugins:maven-enforcer-plugin:1.0.1:enforce' with
> >> >> basic configurator -->
> >> >> [DEBUG] (s) fail = true
> >> >> [DEBUG] (s) failFast = false
> >> >> [DEBUG] (f) ignoreCache = false
> >> >> [DEBUG] (s) project = MavenProject:
> >> >> org.apache.accumulo:accumulo:1.5.0-SNAPSHOT @
> >> >> /Users/benson/asf/accumulo/pom.xml
> >> >> [DEBUG] (s) version = [2.2.0,)
> >> >> [DEBUG] (s) rules =
> >> >> [org.apache.maven.plugins.enforcer.RequireMavenVersion@42c31c7d]
> >> >> [DEBUG] (s) session =
> >> >> org.apache.maven.execution.MavenSession@409bad4f
> >> >> [DEBUG] (s) skip = false
> >> >> [DEBUG] -- end configuration --
> >> >> [DEBUG] Executing rule:
> >> >> org.apache.maven.plugins.enforcer.RequireMavenVersion [DEBUG] Rule
> >> >> org.apache.maven.plugins.enforcer.RequireMavenVersion is cacheable.
> >> >> [DEBUG] Detected Maven Version: 3.0.4
> >> >> [DEBUG] Detected Maven Version: 3.0.4 is allowed in the range
> >> >> [2.2.0,).
> >> >> [INFO]
> >> >> [INFO]
> >> >>
> >> >> [INFO] Forking cloudtrace 1.5.0-SNAPSHOT
> >> >> [INFO]
> >> >>
> >> >>
> >> >> On Mon, Nov 19, 2012 at 12:10 AM, Barrie Treloar <ba...@gmail.com>
> >
> > wrote:
> >> >>> On Mon, Nov 19, 2012 at 11:32 AM, Benson Margulies
> >> >>>
> >> >>> <bi...@gmail.com> wrote:
> >> >>>> Barrie, I understand this much, but what I don't understand is what
> >> >>>> to
> >> >>>> do about it. Is there any choice other than to stop using reporting
> >> >>>> plugins that do the forking? Or can I put the executions of them
> >> >>>> ahead
> >> >>>> of site:site on the command line or something?
> >> >>>
> >> >>> I think the technical term is SOL.
> >> >>> Unless there is a "no-fork" variant of the goal.
> >> >>>
> >> >>> I've only noticed this to be a problem more recently so I haven't had
> >> >>> the time to give it much more thought.
> >> >>> The knee jerk reaction is that "fork" should be deprecated and
> >> >>> replaced with an alternative model.
> >> >>>
> >> >>> ---------------------------------------------------------------------
> >> >>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> >>> For additional commands, e-mail: dev-help@maven.apache.org
> >> >
> >> > ---------------------------------------------------------------------
> >> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Site plugin and forked executions
Posted by Benson Margulies <bi...@gmail.com>.
On Tue, Nov 27, 2012 at 8:48 PM, Hervé BOUTEMY <he...@free.fr> wrote:
> I had a second thought about aggregate reporting plugins (or more precisely
> goal).
>
> Since some time, we're applying a new pattern where there is a separate
> reporting goal for aggregate (previously, aggregate was a parameter).
> In the maven parent pom, we're explicitely setting a reportSet configuration
> for m-javadoc-p, which is the first plugin implementing this pattern IIRC.
> But for other plugins, we don't define reportSets: then by default, every
> reporting goals are used, ie aggregate and non-aggregate.
>
> Now I understand why I'm experiencing twice PMD or Checkstyle runs in
> components lately...
Now there's no use of the aggregate reportSet. If we wanted
aggregation, how would we write it do happen in the right place?
>
> I just created MPOM-39 for tracking this issue.
>
> Regards,
>
> Hervé
>
>
> [1] https://issues.apache.org/jira/browse/MPOM-39
> Le lundi 19 novembre 2012 20:50:07 Dennis Lundberg a écrit :
>> Hi
>>
>> Yes, most likely. There are a bunch of JIRAs for the Site Plugin about
>> issues like the one you're experiencing. The two things that stands out
>> from memory are:
>>
>> - aggregate reporting plugins (like Javadoc in your example)
>> - using the "new" way of configuring reporting plugins, i.e. under the
>> Site Plugin's configuration> element
>>
>> I try to stay away from both if I can...
>>
>> On 2012-11-19 14:31, Benson Margulies wrote:
>> > Or is this the real villan:
>> >
>> > [DEBUG] Lifecycle site -> [pre-site, site, post-site, site-deploy]
>> > [INFO]
>> > [INFO] >>> maven-javadoc-plugin:2.9:aggregate (report:aggregate) @
>> > accumulo >>> [INFO]
>> > [INFO]
>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> > [INFO] Forking accumulo 1.5.0-SNAPSHOT
>> > [INFO]
>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> > On Mon, Nov 19, 2012 at 8:30 AM, Benson Margulies <bi...@gmail.com>
> wrote:
>> >> Does the below show the enforcer plugin, of all things, forking?
>> >>
>> >> [DEBUG] Configuring mojo
>> >> 'org.apache.maven.plugins:maven-enforcer-plugin:1.0.1:enforce' with
>> >> basic configurator -->
>> >> [DEBUG] (s) fail = true
>> >> [DEBUG] (s) failFast = false
>> >> [DEBUG] (f) ignoreCache = false
>> >> [DEBUG] (s) project = MavenProject:
>> >> org.apache.accumulo:accumulo:1.5.0-SNAPSHOT @
>> >> /Users/benson/asf/accumulo/pom.xml
>> >> [DEBUG] (s) version = [2.2.0,)
>> >> [DEBUG] (s) rules =
>> >> [org.apache.maven.plugins.enforcer.RequireMavenVersion@42c31c7d]
>> >> [DEBUG] (s) session = org.apache.maven.execution.MavenSession@409bad4f
>> >> [DEBUG] (s) skip = false
>> >> [DEBUG] -- end configuration --
>> >> [DEBUG] Executing rule:
>> >> org.apache.maven.plugins.enforcer.RequireMavenVersion [DEBUG] Rule
>> >> org.apache.maven.plugins.enforcer.RequireMavenVersion is cacheable.
>> >> [DEBUG] Detected Maven Version: 3.0.4
>> >> [DEBUG] Detected Maven Version: 3.0.4 is allowed in the range [2.2.0,).
>> >> [INFO]
>> >> [INFO]
>> >> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> >> [INFO] Forking cloudtrace 1.5.0-SNAPSHOT
>> >> [INFO]
>> >>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> >> On Mon, Nov 19, 2012 at 12:10 AM, Barrie Treloar <ba...@gmail.com>
> wrote:
>> >>> On Mon, Nov 19, 2012 at 11:32 AM, Benson Margulies
>> >>>
>> >>> <bi...@gmail.com> wrote:
>> >>>> Barrie, I understand this much, but what I don't understand is what to
>> >>>> do about it. Is there any choice other than to stop using reporting
>> >>>> plugins that do the forking? Or can I put the executions of them ahead
>> >>>> of site:site on the command line or something?
>> >>>
>> >>> I think the technical term is SOL.
>> >>> Unless there is a "no-fork" variant of the goal.
>> >>>
>> >>> I've only noticed this to be a problem more recently so I haven't had
>> >>> the time to give it much more thought.
>> >>> The knee jerk reaction is that "fork" should be deprecated and
>> >>> replaced with an alternative model.
>> >>>
>> >>> ---------------------------------------------------------------------
>> >>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> >>> For additional commands, e-mail: dev-help@maven.apache.org
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> > For additional commands, e-mail: dev-help@maven.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Site plugin and forked executions
Posted by Hervé BOUTEMY <he...@free.fr>.
I had a second thought about aggregate reporting plugins (or more precisely
goal).
Since some time, we're applying a new pattern where there is a separate
reporting goal for aggregate (previously, aggregate was a parameter).
In the maven parent pom, we're explicitely setting a reportSet configuration
for m-javadoc-p, which is the first plugin implementing this pattern IIRC.
But for other plugins, we don't define reportSets: then by default, every
reporting goals are used, ie aggregate and non-aggregate.
Now I understand why I'm experiencing twice PMD or Checkstyle runs in
components lately...
I just created MPOM-39 for tracking this issue.
Regards,
Hervé
[1] https://issues.apache.org/jira/browse/MPOM-39
Le lundi 19 novembre 2012 20:50:07 Dennis Lundberg a écrit :
> Hi
>
> Yes, most likely. There are a bunch of JIRAs for the Site Plugin about
> issues like the one you're experiencing. The two things that stands out
> from memory are:
>
> - aggregate reporting plugins (like Javadoc in your example)
> - using the "new" way of configuring reporting plugins, i.e. under the
> Site Plugin's configuration> element
>
> I try to stay away from both if I can...
>
> On 2012-11-19 14:31, Benson Margulies wrote:
> > Or is this the real villan:
> >
> > [DEBUG] Lifecycle site -> [pre-site, site, post-site, site-deploy]
> > [INFO]
> > [INFO] >>> maven-javadoc-plugin:2.9:aggregate (report:aggregate) @
> > accumulo >>> [INFO]
> > [INFO]
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > [INFO] Forking accumulo 1.5.0-SNAPSHOT
> > [INFO]
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > On Mon, Nov 19, 2012 at 8:30 AM, Benson Margulies <bi...@gmail.com>
wrote:
> >> Does the below show the enforcer plugin, of all things, forking?
> >>
> >> [DEBUG] Configuring mojo
> >> 'org.apache.maven.plugins:maven-enforcer-plugin:1.0.1:enforce' with
> >> basic configurator -->
> >> [DEBUG] (s) fail = true
> >> [DEBUG] (s) failFast = false
> >> [DEBUG] (f) ignoreCache = false
> >> [DEBUG] (s) project = MavenProject:
> >> org.apache.accumulo:accumulo:1.5.0-SNAPSHOT @
> >> /Users/benson/asf/accumulo/pom.xml
> >> [DEBUG] (s) version = [2.2.0,)
> >> [DEBUG] (s) rules =
> >> [org.apache.maven.plugins.enforcer.RequireMavenVersion@42c31c7d]
> >> [DEBUG] (s) session = org.apache.maven.execution.MavenSession@409bad4f
> >> [DEBUG] (s) skip = false
> >> [DEBUG] -- end configuration --
> >> [DEBUG] Executing rule:
> >> org.apache.maven.plugins.enforcer.RequireMavenVersion [DEBUG] Rule
> >> org.apache.maven.plugins.enforcer.RequireMavenVersion is cacheable.
> >> [DEBUG] Detected Maven Version: 3.0.4
> >> [DEBUG] Detected Maven Version: 3.0.4 is allowed in the range [2.2.0,).
> >> [INFO]
> >> [INFO]
> >> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> [INFO] Forking cloudtrace 1.5.0-SNAPSHOT
> >> [INFO]
> >>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> On Mon, Nov 19, 2012 at 12:10 AM, Barrie Treloar <ba...@gmail.com>
wrote:
> >>> On Mon, Nov 19, 2012 at 11:32 AM, Benson Margulies
> >>>
> >>> <bi...@gmail.com> wrote:
> >>>> Barrie, I understand this much, but what I don't understand is what to
> >>>> do about it. Is there any choice other than to stop using reporting
> >>>> plugins that do the forking? Or can I put the executions of them ahead
> >>>> of site:site on the command line or something?
> >>>
> >>> I think the technical term is SOL.
> >>> Unless there is a "no-fork" variant of the goal.
> >>>
> >>> I've only noticed this to be a problem more recently so I haven't had
> >>> the time to give it much more thought.
> >>> The knee jerk reaction is that "fork" should be deprecated and
> >>> replaced with an alternative model.
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >>> For additional commands, e-mail: dev-help@maven.apache.org
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Site plugin and forked executions
Posted by Barrie Treloar <ba...@gmail.com>.
Feel like doing the manual cleansing of the output file and just keep
* lifecycle events
> [DEBUG] Lifecycle site -> [pre-site, site, post-site, site-deploy]
* plugin details
> [INFO] >>> maven-javadoc-plugin:2.9:aggregate (report:aggregate) @ accumulo >>>
* forking info messages
> [INFO] >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> [INFO] Forking accumulo 1.5.0-SNAPSHOT
> [INFO] >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
At least you can get a few more eyes having a look at the problem.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Site plugin and forked executions
Posted by Benson Margulies <bi...@gmail.com>.
The second wasn't involved in this case. The first was.
On Mon, Nov 19, 2012 at 2:50 PM, Dennis Lundberg <de...@apache.org> wrote:
> Hi
>
> Yes, most likely. There are a bunch of JIRAs for the Site Plugin about
> issues like the one you're experiencing. The two things that stands out
> from memory are:
>
> - aggregate reporting plugins (like Javadoc in your example)
> - using the "new" way of configuring reporting plugins, i.e. under the
> Site Plugin's configuration> element
>
> I try to stay away from both if I can...
>
> On 2012-11-19 14:31, Benson Margulies wrote:
>> Or is this the real villan:
>>
>> [DEBUG] Lifecycle site -> [pre-site, site, post-site, site-deploy]
>> [INFO]
>> [INFO] >>> maven-javadoc-plugin:2.9:aggregate (report:aggregate) @ accumulo >>>
>> [INFO]
>> [INFO] >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> [INFO] Forking accumulo 1.5.0-SNAPSHOT
>> [INFO] >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>
>> On Mon, Nov 19, 2012 at 8:30 AM, Benson Margulies <bi...@gmail.com> wrote:
>>> Does the below show the enforcer plugin, of all things, forking?
>>>
>>> [DEBUG] Configuring mojo
>>> 'org.apache.maven.plugins:maven-enforcer-plugin:1.0.1:enforce' with
>>> basic configurator -->
>>> [DEBUG] (s) fail = true
>>> [DEBUG] (s) failFast = false
>>> [DEBUG] (f) ignoreCache = false
>>> [DEBUG] (s) project = MavenProject:
>>> org.apache.accumulo:accumulo:1.5.0-SNAPSHOT @
>>> /Users/benson/asf/accumulo/pom.xml
>>> [DEBUG] (s) version = [2.2.0,)
>>> [DEBUG] (s) rules =
>>> [org.apache.maven.plugins.enforcer.RequireMavenVersion@42c31c7d]
>>> [DEBUG] (s) session = org.apache.maven.execution.MavenSession@409bad4f
>>> [DEBUG] (s) skip = false
>>> [DEBUG] -- end configuration --
>>> [DEBUG] Executing rule: org.apache.maven.plugins.enforcer.RequireMavenVersion
>>> [DEBUG] Rule org.apache.maven.plugins.enforcer.RequireMavenVersion is cacheable.
>>> [DEBUG] Detected Maven Version: 3.0.4
>>> [DEBUG] Detected Maven Version: 3.0.4 is allowed in the range [2.2.0,).
>>> [INFO]
>>> [INFO] >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>> [INFO] Forking cloudtrace 1.5.0-SNAPSHOT
>>> [INFO] >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>
>>>
>>> On Mon, Nov 19, 2012 at 12:10 AM, Barrie Treloar <ba...@gmail.com> wrote:
>>>> On Mon, Nov 19, 2012 at 11:32 AM, Benson Margulies
>>>> <bi...@gmail.com> wrote:
>>>>> Barrie, I understand this much, but what I don't understand is what to
>>>>> do about it. Is there any choice other than to stop using reporting
>>>>> plugins that do the forking? Or can I put the executions of them ahead
>>>>> of site:site on the command line or something?
>>>>
>>>> I think the technical term is SOL.
>>>> Unless there is a "no-fork" variant of the goal.
>>>>
>>>> I've only noticed this to be a problem more recently so I haven't had
>>>> the time to give it much more thought.
>>>> The knee jerk reaction is that "fork" should be deprecated and
>>>> replaced with an alternative model.
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
>
> --
> Dennis Lundberg
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Site plugin and forked executions
Posted by Dennis Lundberg <de...@apache.org>.
Hi
Yes, most likely. There are a bunch of JIRAs for the Site Plugin about
issues like the one you're experiencing. The two things that stands out
from memory are:
- aggregate reporting plugins (like Javadoc in your example)
- using the "new" way of configuring reporting plugins, i.e. under the
Site Plugin's configuration> element
I try to stay away from both if I can...
On 2012-11-19 14:31, Benson Margulies wrote:
> Or is this the real villan:
>
> [DEBUG] Lifecycle site -> [pre-site, site, post-site, site-deploy]
> [INFO]
> [INFO] >>> maven-javadoc-plugin:2.9:aggregate (report:aggregate) @ accumulo >>>
> [INFO]
> [INFO] >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> [INFO] Forking accumulo 1.5.0-SNAPSHOT
> [INFO] >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>
> On Mon, Nov 19, 2012 at 8:30 AM, Benson Margulies <bi...@gmail.com> wrote:
>> Does the below show the enforcer plugin, of all things, forking?
>>
>> [DEBUG] Configuring mojo
>> 'org.apache.maven.plugins:maven-enforcer-plugin:1.0.1:enforce' with
>> basic configurator -->
>> [DEBUG] (s) fail = true
>> [DEBUG] (s) failFast = false
>> [DEBUG] (f) ignoreCache = false
>> [DEBUG] (s) project = MavenProject:
>> org.apache.accumulo:accumulo:1.5.0-SNAPSHOT @
>> /Users/benson/asf/accumulo/pom.xml
>> [DEBUG] (s) version = [2.2.0,)
>> [DEBUG] (s) rules =
>> [org.apache.maven.plugins.enforcer.RequireMavenVersion@42c31c7d]
>> [DEBUG] (s) session = org.apache.maven.execution.MavenSession@409bad4f
>> [DEBUG] (s) skip = false
>> [DEBUG] -- end configuration --
>> [DEBUG] Executing rule: org.apache.maven.plugins.enforcer.RequireMavenVersion
>> [DEBUG] Rule org.apache.maven.plugins.enforcer.RequireMavenVersion is cacheable.
>> [DEBUG] Detected Maven Version: 3.0.4
>> [DEBUG] Detected Maven Version: 3.0.4 is allowed in the range [2.2.0,).
>> [INFO]
>> [INFO] >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> [INFO] Forking cloudtrace 1.5.0-SNAPSHOT
>> [INFO] >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>
>>
>> On Mon, Nov 19, 2012 at 12:10 AM, Barrie Treloar <ba...@gmail.com> wrote:
>>> On Mon, Nov 19, 2012 at 11:32 AM, Benson Margulies
>>> <bi...@gmail.com> wrote:
>>>> Barrie, I understand this much, but what I don't understand is what to
>>>> do about it. Is there any choice other than to stop using reporting
>>>> plugins that do the forking? Or can I put the executions of them ahead
>>>> of site:site on the command line or something?
>>>
>>> I think the technical term is SOL.
>>> Unless there is a "no-fork" variant of the goal.
>>>
>>> I've only noticed this to be a problem more recently so I haven't had
>>> the time to give it much more thought.
>>> The knee jerk reaction is that "fork" should be deprecated and
>>> replaced with an alternative model.
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
--
Dennis Lundberg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Site plugin and forked executions
Posted by Benson Margulies <bi...@gmail.com>.
Or is this the real villan:
[DEBUG] Lifecycle site -> [pre-site, site, post-site, site-deploy]
[INFO]
[INFO] >>> maven-javadoc-plugin:2.9:aggregate (report:aggregate) @ accumulo >>>
[INFO]
[INFO] >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
[INFO] Forking accumulo 1.5.0-SNAPSHOT
[INFO] >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
On Mon, Nov 19, 2012 at 8:30 AM, Benson Margulies <bi...@gmail.com> wrote:
> Does the below show the enforcer plugin, of all things, forking?
>
> [DEBUG] Configuring mojo
> 'org.apache.maven.plugins:maven-enforcer-plugin:1.0.1:enforce' with
> basic configurator -->
> [DEBUG] (s) fail = true
> [DEBUG] (s) failFast = false
> [DEBUG] (f) ignoreCache = false
> [DEBUG] (s) project = MavenProject:
> org.apache.accumulo:accumulo:1.5.0-SNAPSHOT @
> /Users/benson/asf/accumulo/pom.xml
> [DEBUG] (s) version = [2.2.0,)
> [DEBUG] (s) rules =
> [org.apache.maven.plugins.enforcer.RequireMavenVersion@42c31c7d]
> [DEBUG] (s) session = org.apache.maven.execution.MavenSession@409bad4f
> [DEBUG] (s) skip = false
> [DEBUG] -- end configuration --
> [DEBUG] Executing rule: org.apache.maven.plugins.enforcer.RequireMavenVersion
> [DEBUG] Rule org.apache.maven.plugins.enforcer.RequireMavenVersion is cacheable.
> [DEBUG] Detected Maven Version: 3.0.4
> [DEBUG] Detected Maven Version: 3.0.4 is allowed in the range [2.2.0,).
> [INFO]
> [INFO] >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> [INFO] Forking cloudtrace 1.5.0-SNAPSHOT
> [INFO] >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>
>
> On Mon, Nov 19, 2012 at 12:10 AM, Barrie Treloar <ba...@gmail.com> wrote:
>> On Mon, Nov 19, 2012 at 11:32 AM, Benson Margulies
>> <bi...@gmail.com> wrote:
>>> Barrie, I understand this much, but what I don't understand is what to
>>> do about it. Is there any choice other than to stop using reporting
>>> plugins that do the forking? Or can I put the executions of them ahead
>>> of site:site on the command line or something?
>>
>> I think the technical term is SOL.
>> Unless there is a "no-fork" variant of the goal.
>>
>> I've only noticed this to be a problem more recently so I haven't had
>> the time to give it much more thought.
>> The knee jerk reaction is that "fork" should be deprecated and
>> replaced with an alternative model.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Site plugin and forked executions
Posted by Benson Margulies <bi...@gmail.com>.
Does the below show the enforcer plugin, of all things, forking?
[DEBUG] Configuring mojo
'org.apache.maven.plugins:maven-enforcer-plugin:1.0.1:enforce' with
basic configurator -->
[DEBUG] (s) fail = true
[DEBUG] (s) failFast = false
[DEBUG] (f) ignoreCache = false
[DEBUG] (s) project = MavenProject:
org.apache.accumulo:accumulo:1.5.0-SNAPSHOT @
/Users/benson/asf/accumulo/pom.xml
[DEBUG] (s) version = [2.2.0,)
[DEBUG] (s) rules =
[org.apache.maven.plugins.enforcer.RequireMavenVersion@42c31c7d]
[DEBUG] (s) session = org.apache.maven.execution.MavenSession@409bad4f
[DEBUG] (s) skip = false
[DEBUG] -- end configuration --
[DEBUG] Executing rule: org.apache.maven.plugins.enforcer.RequireMavenVersion
[DEBUG] Rule org.apache.maven.plugins.enforcer.RequireMavenVersion is cacheable.
[DEBUG] Detected Maven Version: 3.0.4
[DEBUG] Detected Maven Version: 3.0.4 is allowed in the range [2.2.0,).
[INFO]
[INFO] >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
[INFO] Forking cloudtrace 1.5.0-SNAPSHOT
[INFO] >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
On Mon, Nov 19, 2012 at 12:10 AM, Barrie Treloar <ba...@gmail.com> wrote:
> On Mon, Nov 19, 2012 at 11:32 AM, Benson Margulies
> <bi...@gmail.com> wrote:
>> Barrie, I understand this much, but what I don't understand is what to
>> do about it. Is there any choice other than to stop using reporting
>> plugins that do the forking? Or can I put the executions of them ahead
>> of site:site on the command line or something?
>
> I think the technical term is SOL.
> Unless there is a "no-fork" variant of the goal.
>
> I've only noticed this to be a problem more recently so I haven't had
> the time to give it much more thought.
> The knee jerk reaction is that "fork" should be deprecated and
> replaced with an alternative model.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Site plugin and forked executions
Posted by Barrie Treloar <ba...@gmail.com>.
On Mon, Nov 19, 2012 at 11:32 AM, Benson Margulies
<bi...@gmail.com> wrote:
> Barrie, I understand this much, but what I don't understand is what to
> do about it. Is there any choice other than to stop using reporting
> plugins that do the forking? Or can I put the executions of them ahead
> of site:site on the command line or something?
I think the technical term is SOL.
Unless there is a "no-fork" variant of the goal.
I've only noticed this to be a problem more recently so I haven't had
the time to give it much more thought.
The knee jerk reaction is that "fork" should be deprecated and
replaced with an alternative model.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Site plugin and forked executions
Posted by Benson Margulies <bi...@gmail.com>.
On Sun, Nov 18, 2012 at 7:13 PM, Barrie Treloar <ba...@gmail.com> wrote:
> On Mon, Nov 19, 2012 at 9:39 AM, Brett Porter <br...@apache.org> wrote:
>> As Hervé says, it'll depend on the reports you're using. Cobertura forks to ensure the tests are run with the instrumented classes - though I believe most code coverage plugins have some options to inject that into your main build stream and then produce the report on the data at the end.
>
> There is another post I've made because I have had this problem in the past.
>
> My resolution is to use -X and pipe the output to a file.
>
> Then manually go through and Maven 3 has excellent comments about what
> it is doing so it is obvious where a plugin is starting and
> potentially forking.
> I just deleted everything but those markers and then analyze what they
> are telling me.
>
> I recommend doing this in two steps, 1) delete everything else 2) analyze.
> As trying to scan through the file by eye misses things and caused me
> to head off in the wrong directions.
> Once I had just the bits I needed it was obvious where the problem was.
>
> Which probably brings us to the logging discussion currently going on...
Barrie, I understand this much, but what I don't understand is what to
do about it. Is there any choice other than to stop using reporting
plugins that do the forking? Or can I put the executions of them ahead
of site:site on the command line or something?
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Site plugin and forked executions
Posted by Barrie Treloar <ba...@gmail.com>.
On Mon, Nov 19, 2012 at 9:39 AM, Brett Porter <br...@apache.org> wrote:
> As Hervé says, it'll depend on the reports you're using. Cobertura forks to ensure the tests are run with the instrumented classes - though I believe most code coverage plugins have some options to inject that into your main build stream and then produce the report on the data at the end.
There is another post I've made because I have had this problem in the past.
My resolution is to use -X and pipe the output to a file.
Then manually go through and Maven 3 has excellent comments about what
it is doing so it is obvious where a plugin is starting and
potentially forking.
I just deleted everything but those markers and then analyze what they
are telling me.
I recommend doing this in two steps, 1) delete everything else 2) analyze.
As trying to scan through the file by eye misses things and caused me
to head off in the wrong directions.
Once I had just the bits I needed it was obvious where the problem was.
Which probably brings us to the logging discussion currently going on...
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Site plugin and forked executions
Posted by Brett Porter <br...@apache.org>.
As Hervé says, it'll depend on the reports you're using. Cobertura forks to ensure the tests are run with the instrumented classes - though I believe most code coverage plugins have some options to inject that into your main build stream and then produce the report on the data at the end.
- Brett
On 19/11/2012, at 9:52 AM, Hervé BOUTEMY <he...@free.fr> wrote:
> cobertura, another usual suspect
>
> I really don't understand this aspect, and for the moment, I gave up...
>
> Le dimanche 18 novembre 2012 17:50:02 Benson Margulies a écrit :
>> On Sun, Nov 18, 2012 at 5:45 PM, Hervé BOUTEMY <he...@free.fr>
> wrote:
>>> Le dimanche 18 novembre 2012 17:24:14 Benson Margulies a écrit :
>>>> Folks,
>>>>
>>>> I myself feel like a bit of a looping site build myself on this
>>>> subject, and I apologize.
>>>>
>>>> The build of Apache Accumulo is showing the 'classic' symptoms of
>>>> running more or less forever with 'site:site', due, apparently, to
>>>> some forked execution that causes it to do the same things over and
>>>> over.
>>>>
>>>> Is this really the intended behavior?
>>>
>>> of course not
>>>
>>>> I'd like to help cure it, but I am still very much feeling an idiot
>>>> about the whole business.
>>>
>>> this is something really hard to understand then to fix: I'm fighting
>>> against such case for a long time now. There was some time I didn't see
>>> such a problem.
>>> From what I understand, the m-site-p doesn't fork executions but some
>>> plugins do, like m-javadoc-p. Perhaps a consequence of MJAVADOC-171?
>>> Try to remove some javadoc reports, it can help...
>>
>> In my past life, javadoc loomed large here. In the accumulo build,
>> what looks most suspicious is cobertura, which is a big forker of
>> executions.
>>
>> However, given that there are reporting plugins that *do* fork
>> executions, what can we do here? Somehow, don't we want to limit the
>> execution plans in the forked executions to avoid all this redundancy?
>>
>>> (sorry, no better idea...)
>>>
>>> Regards,
>>>
>>> Hervé
>>>
>>>> --benson
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
--
Brett Porter
brett@apache.org
http://brettporter.wordpress.com/
http://au.linkedin.com/in/brettporter
http://twitter.com/brettporter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Site plugin and forked executions
Posted by Hervé BOUTEMY <he...@free.fr>.
cobertura, another usual suspect
I really don't understand this aspect, and for the moment, I gave up...
Le dimanche 18 novembre 2012 17:50:02 Benson Margulies a écrit :
> On Sun, Nov 18, 2012 at 5:45 PM, Hervé BOUTEMY <he...@free.fr>
wrote:
> > Le dimanche 18 novembre 2012 17:24:14 Benson Margulies a écrit :
> >> Folks,
> >>
> >> I myself feel like a bit of a looping site build myself on this
> >> subject, and I apologize.
> >>
> >> The build of Apache Accumulo is showing the 'classic' symptoms of
> >> running more or less forever with 'site:site', due, apparently, to
> >> some forked execution that causes it to do the same things over and
> >> over.
> >>
> >> Is this really the intended behavior?
> >
> > of course not
> >
> >> I'd like to help cure it, but I am still very much feeling an idiot
> >> about the whole business.
> >
> > this is something really hard to understand then to fix: I'm fighting
> > against such case for a long time now. There was some time I didn't see
> > such a problem.
> > From what I understand, the m-site-p doesn't fork executions but some
> > plugins do, like m-javadoc-p. Perhaps a consequence of MJAVADOC-171?
> > Try to remove some javadoc reports, it can help...
>
> In my past life, javadoc loomed large here. In the accumulo build,
> what looks most suspicious is cobertura, which is a big forker of
> executions.
>
> However, given that there are reporting plugins that *do* fork
> executions, what can we do here? Somehow, don't we want to limit the
> execution plans in the forked executions to avoid all this redundancy?
>
> > (sorry, no better idea...)
> >
> > Regards,
> >
> > Hervé
> >
> >> --benson
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> For additional commands, e-mail: dev-help@maven.apache.org
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Site plugin and forked executions
Posted by Benson Margulies <bi...@gmail.com>.
On Sun, Nov 18, 2012 at 5:45 PM, Hervé BOUTEMY <he...@free.fr> wrote:
> Le dimanche 18 novembre 2012 17:24:14 Benson Margulies a écrit :
>> Folks,
>>
>> I myself feel like a bit of a looping site build myself on this
>> subject, and I apologize.
>>
>> The build of Apache Accumulo is showing the 'classic' symptoms of
>> running more or less forever with 'site:site', due, apparently, to
>> some forked execution that causes it to do the same things over and
>> over.
>>
>> Is this really the intended behavior?
> of course not
>
>>
>> I'd like to help cure it, but I am still very much feeling an idiot
>> about the whole business.
> this is something really hard to understand then to fix: I'm fighting against
> such case for a long time now. There was some time I didn't see such a
> problem.
> From what I understand, the m-site-p doesn't fork executions but some plugins
> do, like m-javadoc-p. Perhaps a consequence of MJAVADOC-171?
> Try to remove some javadoc reports, it can help...
In my past life, javadoc loomed large here. In the accumulo build,
what looks most suspicious is cobertura, which is a big forker of
executions.
However, given that there are reporting plugins that *do* fork
executions, what can we do here? Somehow, don't we want to limit the
execution plans in the forked executions to avoid all this redundancy?
>
> (sorry, no better idea...)
>
> Regards,
>
> Hervé
>
>>
>> --benson
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Site plugin and forked executions
Posted by Hervé BOUTEMY <he...@free.fr>.
Le dimanche 18 novembre 2012 17:24:14 Benson Margulies a écrit :
> Folks,
>
> I myself feel like a bit of a looping site build myself on this
> subject, and I apologize.
>
> The build of Apache Accumulo is showing the 'classic' symptoms of
> running more or less forever with 'site:site', due, apparently, to
> some forked execution that causes it to do the same things over and
> over.
>
> Is this really the intended behavior?
of course not
>
> I'd like to help cure it, but I am still very much feeling an idiot
> about the whole business.
this is something really hard to understand then to fix: I'm fighting against
such case for a long time now. There was some time I didn't see such a
problem.
>From what I understand, the m-site-p doesn't fork executions but some plugins
do, like m-javadoc-p. Perhaps a consequence of MJAVADOC-171?
Try to remove some javadoc reports, it can help...
(sorry, no better idea...)
Regards,
Hervé
>
> --benson
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org