You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by David Hoffer <dh...@gmail.com> on 2009/09/24 23:18:53 UTC
why does site-deploy rebuild so often?
We keep having problems with our site-deploy build either hanging or running
out of memory. I just noticed that it rebuilds everything about 11 times!
Why?
(This top level pom has 3 modules where those 3 modules each have a few
modules. This is the only pom with a reporting section.)
Here is our top level reporting section.
<reporting>
<plugins>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>javancss-maven-plugin</artifactId>
<version>2.0-beta-2</version>
</plugin>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>cobertura-maven-plugin</artifactId>
<version>${cobertura-maven-plugin.version}</version>
</plugin>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>surefire-report-maven-plugin</artifactId>
<version>2.0-beta-1</version>
</plugin>
<plugin>
<!--Provides creating jar of source-->
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-source-plugin</artifactId>
<version>${maven-source-plugin.version}</version>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-javadoc-plugin</artifactId>
<version>${maven-javadoc-plugin.version}</version>
<configuration>
<aggregate>true</aggregate>
</configuration>
</plugin>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>jxr-maven-plugin</artifactId>
<version>2.0-beta-1</version>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-pmd-plugin</artifactId>
<version>2.4</version>
<configuration>
<targetjdk>${jdkVersion}</targetjdk>
<rulesets>
<ruleset>/rulesets/basic.xml</ruleset>
</rulesets>
<format>xml</format>
<linkXref>true</linkXref>
<sourceEncoding>utf-8</sourceEncoding>
<minimumTokens>100</minimumTokens>
</configuration>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-project-info-reports-plugin</artifactId>
<version>2.1.1</version>
<reportSets>
<reportSet>
<reports>
<report>dependencies</report>
<report>dependency-convergence</report>
<report>project-team</report>
<report>cim</report>
<report>license</report>
<report>scm</report>
<report>index</report>
<report>summary</report>
</reports>
</reportSet>
</reportSets>
</plugin>
</plugins>
</reporting>
Re: why does site-deploy rebuild so often?
Posted by Lee Meador <le...@leemeador.com>.
This can also cause problems if you have, for example, ant tasks in the
build (or generate-sources) phases that take a long time. Everyone of the
re-do parts repeats that long build. It's not like a compile where javac
doesn't recompile whatever is already compiled.
I have added stuff to ant tasks (in this case, to generate java source for
web service clients) so that they check whether the output of the task is
already there and newer than something used to generate them. [I feel like
I'm rewriting 'make' inside an ant script.] The clean will get rid of all
the generated stuff and the 1st build will create it but the subsequent ones
won't.
It's a pain but makes the site build much more manageable. Doing this
consistently lets my build finish in less memory.
-- Lee
On Fri, Sep 25, 2009 at 11:01 AM, Stephen Connolly <
stephen.alan.connolly@gmail.com> wrote:
> If you don't need the report on every module I would only specify the
> report on the modules that require it.
>
> In this respect the <reporting> section is badly let down by the lack
> of a <pluginManagement> section... but that would require a schema
> change... and I am not sure I see that happening any time soon... but
> you could always ask Jason! ;-)
>
> -Stephen
>
> 2009/9/25 David Hoffer <dh...@gmail.com>:
> > Just a couple more ideas/questions.
> >
> > Currently we specify our reports at the top level only. Is there a way
> to
> > exclude some reports on child modules? Or should we be specifying our
> > reports at each child module level where we need the report and not at
> the
> > top level? I.e. what's the best way to just run the minimum number of
> > reports, so we use less memory?
> >
> > -Dave
> >
> > On Fri, Sep 25, 2009 at 7:06 AM, David Hoffer <dh...@gmail.com>
> wrote:
> >
> >> Thanks for the explanation that makes sense. I'm surprised maven
> reporting
> >> is designed so poorly, I agree your approach in the invoker makes more
> >> sense.
> >>
> >> BTW, when you say 'fork a build', is this done in the current VM? Is
> there
> >> a way to force all these in separate VMs?
> >>
> >> The problem we have is that as our build gets bigger (they never seem to
> >> get smaller) we are finding that site-deploy is not reliable. Somewhere
> in
> >> the build it will fail, usually because its out of memory. We have
> raised
> >> the max heap to about 2GB, max perm gen to about 350k, etc but some
> piece
> >> will still fail.
> >>
> >> Most often it fails using the exec plugin where we need to call into
> some
> >> Java code. Sometimes the Flex compiler will fail. Etc.
> >>
> >> If we could run each of the reports in a separate VM that would solve
> the
> >> problem, it seems.
> >>
> >> What's the best approach for current users of maven to handle this?
> >>
> >> I suppose we could generate lots of smaller reports each on a section of
> >> the build, etc, but I'd like to investigate other approaches first.
> >>
> >> (BTW, our CI build is on Linux.)
> >>
> >> -Dave
> >>
> >>
> >> On Fri, Sep 25, 2009 at 3:50 AM, Stephen Connolly <
> >> stephen.alan.connolly@gmail.com> wrote:
> >>
> >>> 2009/9/25 David Hoffer <dh...@gmail.com>:
> >>> > Hum,
> >>> >
> >>> > Can you restate/finish the last point 'better still is to switch
> >>> reporting
> >>> > plugins to report, and not to do, and use the build lifecycle for
> >>> doing'?
> >>>
> >>> At the moment, reporting plugins do stuff rather than just generate a
> >>> report of stuff that has already been done.
> >>>
> >>> For example,
> >>>
> >>> the javadoc reporting plugin generates the javadocs... better would be
> >>> to just integrate the already generated javadocs into the site.
> >>>
> >>> the cobertura reporting plugin measures the test coverage... better
> >>> would be to just report the test coverage that was previously measured
> >>> and integrate that report into the site.
> >>>
> >>> Thus reporting plugins would do just that: report
> >>>
> >>> This would keep the reporting lifecycle free from having to fork the
> >>> build lifecycle in order to ensure that the latest results were
> >>> available.
> >>>
> >>> An example of how this works is the maven-invoker-plugin version 1.4,
> >>> where we added a report of the integration tests that have been run.
> >>> That report never forks the build, it just reports on the previous
> >>> results.
> >>>
> >>> With this strategy, you do the work in the build lifecycle... you
> >>> report on the work previously done in the site lifecycle.
> >>>
> >>> > I'm not sure what you are referring to here.
> >>> >
> >>> > Is there a way to know if a reporting plugin is a good or bad one?
> What
> >>> > about the ones I'm using? I'd say the most important are cobertura,
> >>> > javadocs, findbugs (not shown here).
> >>>
> >>> cobertura forks a build lifecycle
> >>>
> >>> javadocs forks a build lifecycle
> >>>
> >>> not sure about findbugs... but it probably forks a build lifecycle in
> >>> order to ensure that all the source code folders are attached to the
> >>> project model and that any generated source code is generated.
> >>>
> >>> >
> >>> > See below for other comments/questions.
> >>> >
> >>> > -Dave
> >>> >
> >>> >
> >>> > On Thu, Sep 24, 2009 at 3:33 PM, Stephen Connolly <
> >>> > stephen.alan.connolly@gmail.com> wrote:
> >>> >
> >>> >> because each of the reporting plugins have no concept of how far up
> the
> >>> >> lifecycle the build has gone
> >>> >>
> >>> >> in maven there are three (3) lifecycles:
> >>> >>
> >>> >> 1. the clean lifecycle: pre-clean, clean and post-clean phases
> >>> >>
> >>> >> 2: the site lifecycle: pre-site, site and site-deploy
> >>> >>
> >>> >> 3. the build lifecycle: validate, ... deploy
> >>> >>
> >>> >> mojos have no way to find out which lifecycle they are running, what
> >>> phase
> >>> >> they are executing in, and what phases have already executed
> >>> >>
> >>> >> thus if you want to report the results of unit tests, you can
> either:
> >>> scan
> >>> >> the filesystem for the results and hope that these results are
> current;
> >>> or
> >>> >> you can fork a build up as far as test and then pull the results
> from
> >>> the
> >>> >> filesystem
> >>> >>
> >>> >
> >>> > [dh] Are you saying that since during reporting surefire has no way
> to
> >>> know
> >>> > if you previously did an install and thus ran the test goal, it will
> >>> fork a
> >>> > new build and run the build lifecycle upto test?
> >>>
> >>> yes
> >>>
> >>> >
> >>> >>
> >>> >> then if you want code coverage...
> >>> >>
> >>> >> if you want to generate javadocs, you need to fork a build up as far
> as
> >>> >> process-sources in order to ensure that the source code has been
> >>> generated
> >>> >> before generating the javadocs
> >>> >>
> >>> >> if you are a good reporting plugin, you will fork the build
> >>> >> non-recursive... bad plugins are aggregator plugins that fork a
> build
> >>> >> (everything is hunky-dory until you have two forking aggregator
> plugins
> >>> in
> >>> >> the same build, as they will recursively fork each other until you
> get
> >>> to a
> >>> >> leaf project)
> >>> >>
> >>> >> 3.x might help solve some of these issues... better still is to
> switch
> >>> >> reporting plugins to report, and not to do, and use the build
> lifecycle
> >>> for
> >>> >> doing
> >>> >>
> >>> > [dh] ??
> >>> >
> >>> >>
> >>> >> Sent from my [rhymes with tryPod] ;-)
> >>> >>
> >>> >>
> >>> >> On 24 Sep 2009, at 22:18, David Hoffer <dh...@gmail.com> wrote:
> >>> >>
> >>> >> We keep having problems with our site-deploy build either hanging
> or
> >>> >>> running
> >>> >>> out of memory. I just noticed that it rebuilds everything about 11
> >>> times!
> >>> >>> Why?
> >>> >>>
> >>> >>> (This top level pom has 3 modules where those 3 modules each have a
> >>> few
> >>> >>> modules. This is the only pom with a reporting section.)
> >>> >>>
> >>> >>> Here is our top level reporting section.
> >>> >>>
> >>> >>> <reporting>
> >>> >>> <plugins>
> >>> >>> <plugin>
> >>> >>> <groupId>org.codehaus.mojo</groupId>
> >>> >>> <artifactId>javancss-maven-plugin</artifactId>
> >>> >>> <version>2.0-beta-2</version>
> >>> >>> </plugin>
> >>> >>> <plugin>
> >>> >>> <groupId>org.codehaus.mojo</groupId>
> >>> >>> <artifactId>cobertura-maven-plugin</artifactId>
> >>> >>> <version>${cobertura-maven-plugin.version}</version>
> >>> >>> </plugin>
> >>> >>> <plugin>
> >>> >>> <groupId>org.codehaus.mojo</groupId>
> >>> >>> <artifactId>surefire-report-maven-plugin</artifactId>
> >>> >>> <version>2.0-beta-1</version>
> >>> >>> </plugin>
> >>> >>> <plugin>
> >>> >>> <!--Provides creating jar of source-->
> >>> >>> <groupId>org.apache.maven.plugins</groupId>
> >>> >>> <artifactId>maven-source-plugin</artifactId>
> >>> >>> <version>${maven-source-plugin.version}</version>
> >>> >>> </plugin>
> >>> >>> <plugin>
> >>> >>> <groupId>org.apache.maven.plugins</groupId>
> >>> >>> <artifactId>maven-javadoc-plugin</artifactId>
> >>> >>> <version>${maven-javadoc-plugin.version}</version>
> >>> >>> <configuration>
> >>> >>> <aggregate>true</aggregate>
> >>> >>> </configuration>
> >>> >>> </plugin>
> >>> >>> <plugin>
> >>> >>> <groupId>org.codehaus.mojo</groupId>
> >>> >>> <artifactId>jxr-maven-plugin</artifactId>
> >>> >>> <version>2.0-beta-1</version>
> >>> >>> </plugin>
> >>> >>> <plugin>
> >>> >>> <groupId>org.apache.maven.plugins</groupId>
> >>> >>> <artifactId>maven-pmd-plugin</artifactId>
> >>> >>> <version>2.4</version>
> >>> >>> <configuration>
> >>> >>> <targetjdk>${jdkVersion}</targetjdk>
> >>> >>> <rulesets>
> >>> >>> <ruleset>/rulesets/basic.xml</ruleset>
> >>> >>> </rulesets>
> >>> >>> <format>xml</format>
> >>> >>> <linkXref>true</linkXref>
> >>> >>> <sourceEncoding>utf-8</sourceEncoding>
> >>> >>> <minimumTokens>100</minimumTokens>
> >>> >>> </configuration>
> >>> >>> </plugin>
> >>> >>> <plugin>
> >>> >>> <groupId>org.apache.maven.plugins</groupId>
> >>> >>>
> >>> <artifactId>maven-project-info-reports-plugin</artifactId>
> >>> >>> <version>2.1.1</version>
> >>> >>> <reportSets>
> >>> >>> <reportSet>
> >>> >>> <reports>
> >>> >>> <report>dependencies</report>
> >>> >>> <report>dependency-convergence</report>
> >>> >>> <report>project-team</report>
> >>> >>> <report>cim</report>
> >>> >>> <report>license</report>
> >>> >>> <report>scm</report>
> >>> >>> <report>index</report>
> >>> >>> <report>summary</report>
> >>> >>> </reports>
> >>> >>> </reportSet>
> >>> >>> </reportSets>
> >>> >>> </plugin>
> >>> >>> </plugins>
> >>> >>> </reporting>
> >>> >>>
> >>> >>
> >>> >>
> ---------------------------------------------------------------------
> >>> >> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> >>> >> For additional commands, e-mail: users-help@maven.apache.org
> >>> >>
> >>> >>
> >>> >
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> >>> For additional commands, e-mail: users-help@maven.apache.org
> >>>
> >>>
> >>
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
--
-- Lee Meador
Sent from gmail. My real email address is lee AT leemeador.com
Re: why does site-deploy rebuild so often?
Posted by Stephen Connolly <st...@gmail.com>.
If you don't need the report on every module I would only specify the
report on the modules that require it.
In this respect the <reporting> section is badly let down by the lack
of a <pluginManagement> section... but that would require a schema
change... and I am not sure I see that happening any time soon... but
you could always ask Jason! ;-)
-Stephen
2009/9/25 David Hoffer <dh...@gmail.com>:
> Just a couple more ideas/questions.
>
> Currently we specify our reports at the top level only. Is there a way to
> exclude some reports on child modules? Or should we be specifying our
> reports at each child module level where we need the report and not at the
> top level? I.e. what's the best way to just run the minimum number of
> reports, so we use less memory?
>
> -Dave
>
> On Fri, Sep 25, 2009 at 7:06 AM, David Hoffer <dh...@gmail.com> wrote:
>
>> Thanks for the explanation that makes sense. I'm surprised maven reporting
>> is designed so poorly, I agree your approach in the invoker makes more
>> sense.
>>
>> BTW, when you say 'fork a build', is this done in the current VM? Is there
>> a way to force all these in separate VMs?
>>
>> The problem we have is that as our build gets bigger (they never seem to
>> get smaller) we are finding that site-deploy is not reliable. Somewhere in
>> the build it will fail, usually because its out of memory. We have raised
>> the max heap to about 2GB, max perm gen to about 350k, etc but some piece
>> will still fail.
>>
>> Most often it fails using the exec plugin where we need to call into some
>> Java code. Sometimes the Flex compiler will fail. Etc.
>>
>> If we could run each of the reports in a separate VM that would solve the
>> problem, it seems.
>>
>> What's the best approach for current users of maven to handle this?
>>
>> I suppose we could generate lots of smaller reports each on a section of
>> the build, etc, but I'd like to investigate other approaches first.
>>
>> (BTW, our CI build is on Linux.)
>>
>> -Dave
>>
>>
>> On Fri, Sep 25, 2009 at 3:50 AM, Stephen Connolly <
>> stephen.alan.connolly@gmail.com> wrote:
>>
>>> 2009/9/25 David Hoffer <dh...@gmail.com>:
>>> > Hum,
>>> >
>>> > Can you restate/finish the last point 'better still is to switch
>>> reporting
>>> > plugins to report, and not to do, and use the build lifecycle for
>>> doing'?
>>>
>>> At the moment, reporting plugins do stuff rather than just generate a
>>> report of stuff that has already been done.
>>>
>>> For example,
>>>
>>> the javadoc reporting plugin generates the javadocs... better would be
>>> to just integrate the already generated javadocs into the site.
>>>
>>> the cobertura reporting plugin measures the test coverage... better
>>> would be to just report the test coverage that was previously measured
>>> and integrate that report into the site.
>>>
>>> Thus reporting plugins would do just that: report
>>>
>>> This would keep the reporting lifecycle free from having to fork the
>>> build lifecycle in order to ensure that the latest results were
>>> available.
>>>
>>> An example of how this works is the maven-invoker-plugin version 1.4,
>>> where we added a report of the integration tests that have been run.
>>> That report never forks the build, it just reports on the previous
>>> results.
>>>
>>> With this strategy, you do the work in the build lifecycle... you
>>> report on the work previously done in the site lifecycle.
>>>
>>> > I'm not sure what you are referring to here.
>>> >
>>> > Is there a way to know if a reporting plugin is a good or bad one? What
>>> > about the ones I'm using? I'd say the most important are cobertura,
>>> > javadocs, findbugs (not shown here).
>>>
>>> cobertura forks a build lifecycle
>>>
>>> javadocs forks a build lifecycle
>>>
>>> not sure about findbugs... but it probably forks a build lifecycle in
>>> order to ensure that all the source code folders are attached to the
>>> project model and that any generated source code is generated.
>>>
>>> >
>>> > See below for other comments/questions.
>>> >
>>> > -Dave
>>> >
>>> >
>>> > On Thu, Sep 24, 2009 at 3:33 PM, Stephen Connolly <
>>> > stephen.alan.connolly@gmail.com> wrote:
>>> >
>>> >> because each of the reporting plugins have no concept of how far up the
>>> >> lifecycle the build has gone
>>> >>
>>> >> in maven there are three (3) lifecycles:
>>> >>
>>> >> 1. the clean lifecycle: pre-clean, clean and post-clean phases
>>> >>
>>> >> 2: the site lifecycle: pre-site, site and site-deploy
>>> >>
>>> >> 3. the build lifecycle: validate, ... deploy
>>> >>
>>> >> mojos have no way to find out which lifecycle they are running, what
>>> phase
>>> >> they are executing in, and what phases have already executed
>>> >>
>>> >> thus if you want to report the results of unit tests, you can either:
>>> scan
>>> >> the filesystem for the results and hope that these results are current;
>>> or
>>> >> you can fork a build up as far as test and then pull the results from
>>> the
>>> >> filesystem
>>> >>
>>> >
>>> > [dh] Are you saying that since during reporting surefire has no way to
>>> know
>>> > if you previously did an install and thus ran the test goal, it will
>>> fork a
>>> > new build and run the build lifecycle upto test?
>>>
>>> yes
>>>
>>> >
>>> >>
>>> >> then if you want code coverage...
>>> >>
>>> >> if you want to generate javadocs, you need to fork a build up as far as
>>> >> process-sources in order to ensure that the source code has been
>>> generated
>>> >> before generating the javadocs
>>> >>
>>> >> if you are a good reporting plugin, you will fork the build
>>> >> non-recursive... bad plugins are aggregator plugins that fork a build
>>> >> (everything is hunky-dory until you have two forking aggregator plugins
>>> in
>>> >> the same build, as they will recursively fork each other until you get
>>> to a
>>> >> leaf project)
>>> >>
>>> >> 3.x might help solve some of these issues... better still is to switch
>>> >> reporting plugins to report, and not to do, and use the build lifecycle
>>> for
>>> >> doing
>>> >>
>>> > [dh] ??
>>> >
>>> >>
>>> >> Sent from my [rhymes with tryPod] ;-)
>>> >>
>>> >>
>>> >> On 24 Sep 2009, at 22:18, David Hoffer <dh...@gmail.com> wrote:
>>> >>
>>> >> We keep having problems with our site-deploy build either hanging or
>>> >>> running
>>> >>> out of memory. I just noticed that it rebuilds everything about 11
>>> times!
>>> >>> Why?
>>> >>>
>>> >>> (This top level pom has 3 modules where those 3 modules each have a
>>> few
>>> >>> modules. This is the only pom with a reporting section.)
>>> >>>
>>> >>> Here is our top level reporting section.
>>> >>>
>>> >>> <reporting>
>>> >>> <plugins>
>>> >>> <plugin>
>>> >>> <groupId>org.codehaus.mojo</groupId>
>>> >>> <artifactId>javancss-maven-plugin</artifactId>
>>> >>> <version>2.0-beta-2</version>
>>> >>> </plugin>
>>> >>> <plugin>
>>> >>> <groupId>org.codehaus.mojo</groupId>
>>> >>> <artifactId>cobertura-maven-plugin</artifactId>
>>> >>> <version>${cobertura-maven-plugin.version}</version>
>>> >>> </plugin>
>>> >>> <plugin>
>>> >>> <groupId>org.codehaus.mojo</groupId>
>>> >>> <artifactId>surefire-report-maven-plugin</artifactId>
>>> >>> <version>2.0-beta-1</version>
>>> >>> </plugin>
>>> >>> <plugin>
>>> >>> <!--Provides creating jar of source-->
>>> >>> <groupId>org.apache.maven.plugins</groupId>
>>> >>> <artifactId>maven-source-plugin</artifactId>
>>> >>> <version>${maven-source-plugin.version}</version>
>>> >>> </plugin>
>>> >>> <plugin>
>>> >>> <groupId>org.apache.maven.plugins</groupId>
>>> >>> <artifactId>maven-javadoc-plugin</artifactId>
>>> >>> <version>${maven-javadoc-plugin.version}</version>
>>> >>> <configuration>
>>> >>> <aggregate>true</aggregate>
>>> >>> </configuration>
>>> >>> </plugin>
>>> >>> <plugin>
>>> >>> <groupId>org.codehaus.mojo</groupId>
>>> >>> <artifactId>jxr-maven-plugin</artifactId>
>>> >>> <version>2.0-beta-1</version>
>>> >>> </plugin>
>>> >>> <plugin>
>>> >>> <groupId>org.apache.maven.plugins</groupId>
>>> >>> <artifactId>maven-pmd-plugin</artifactId>
>>> >>> <version>2.4</version>
>>> >>> <configuration>
>>> >>> <targetjdk>${jdkVersion}</targetjdk>
>>> >>> <rulesets>
>>> >>> <ruleset>/rulesets/basic.xml</ruleset>
>>> >>> </rulesets>
>>> >>> <format>xml</format>
>>> >>> <linkXref>true</linkXref>
>>> >>> <sourceEncoding>utf-8</sourceEncoding>
>>> >>> <minimumTokens>100</minimumTokens>
>>> >>> </configuration>
>>> >>> </plugin>
>>> >>> <plugin>
>>> >>> <groupId>org.apache.maven.plugins</groupId>
>>> >>>
>>> <artifactId>maven-project-info-reports-plugin</artifactId>
>>> >>> <version>2.1.1</version>
>>> >>> <reportSets>
>>> >>> <reportSet>
>>> >>> <reports>
>>> >>> <report>dependencies</report>
>>> >>> <report>dependency-convergence</report>
>>> >>> <report>project-team</report>
>>> >>> <report>cim</report>
>>> >>> <report>license</report>
>>> >>> <report>scm</report>
>>> >>> <report>index</report>
>>> >>> <report>summary</report>
>>> >>> </reports>
>>> >>> </reportSet>
>>> >>> </reportSets>
>>> >>> </plugin>
>>> >>> </plugins>
>>> >>> </reporting>
>>> >>>
>>> >>
>>> >> ---------------------------------------------------------------------
>>> >> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>> >> For additional commands, e-mail: users-help@maven.apache.org
>>> >>
>>> >>
>>> >
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: users-help@maven.apache.org
>>>
>>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: why does site-deploy rebuild so often?
Posted by David Hoffer <dh...@gmail.com>.
Just a couple more ideas/questions.
Currently we specify our reports at the top level only. Is there a way to
exclude some reports on child modules? Or should we be specifying our
reports at each child module level where we need the report and not at the
top level? I.e. what's the best way to just run the minimum number of
reports, so we use less memory?
-Dave
On Fri, Sep 25, 2009 at 7:06 AM, David Hoffer <dh...@gmail.com> wrote:
> Thanks for the explanation that makes sense. I'm surprised maven reporting
> is designed so poorly, I agree your approach in the invoker makes more
> sense.
>
> BTW, when you say 'fork a build', is this done in the current VM? Is there
> a way to force all these in separate VMs?
>
> The problem we have is that as our build gets bigger (they never seem to
> get smaller) we are finding that site-deploy is not reliable. Somewhere in
> the build it will fail, usually because its out of memory. We have raised
> the max heap to about 2GB, max perm gen to about 350k, etc but some piece
> will still fail.
>
> Most often it fails using the exec plugin where we need to call into some
> Java code. Sometimes the Flex compiler will fail. Etc.
>
> If we could run each of the reports in a separate VM that would solve the
> problem, it seems.
>
> What's the best approach for current users of maven to handle this?
>
> I suppose we could generate lots of smaller reports each on a section of
> the build, etc, but I'd like to investigate other approaches first.
>
> (BTW, our CI build is on Linux.)
>
> -Dave
>
>
> On Fri, Sep 25, 2009 at 3:50 AM, Stephen Connolly <
> stephen.alan.connolly@gmail.com> wrote:
>
>> 2009/9/25 David Hoffer <dh...@gmail.com>:
>> > Hum,
>> >
>> > Can you restate/finish the last point 'better still is to switch
>> reporting
>> > plugins to report, and not to do, and use the build lifecycle for
>> doing'?
>>
>> At the moment, reporting plugins do stuff rather than just generate a
>> report of stuff that has already been done.
>>
>> For example,
>>
>> the javadoc reporting plugin generates the javadocs... better would be
>> to just integrate the already generated javadocs into the site.
>>
>> the cobertura reporting plugin measures the test coverage... better
>> would be to just report the test coverage that was previously measured
>> and integrate that report into the site.
>>
>> Thus reporting plugins would do just that: report
>>
>> This would keep the reporting lifecycle free from having to fork the
>> build lifecycle in order to ensure that the latest results were
>> available.
>>
>> An example of how this works is the maven-invoker-plugin version 1.4,
>> where we added a report of the integration tests that have been run.
>> That report never forks the build, it just reports on the previous
>> results.
>>
>> With this strategy, you do the work in the build lifecycle... you
>> report on the work previously done in the site lifecycle.
>>
>> > I'm not sure what you are referring to here.
>> >
>> > Is there a way to know if a reporting plugin is a good or bad one? What
>> > about the ones I'm using? I'd say the most important are cobertura,
>> > javadocs, findbugs (not shown here).
>>
>> cobertura forks a build lifecycle
>>
>> javadocs forks a build lifecycle
>>
>> not sure about findbugs... but it probably forks a build lifecycle in
>> order to ensure that all the source code folders are attached to the
>> project model and that any generated source code is generated.
>>
>> >
>> > See below for other comments/questions.
>> >
>> > -Dave
>> >
>> >
>> > On Thu, Sep 24, 2009 at 3:33 PM, Stephen Connolly <
>> > stephen.alan.connolly@gmail.com> wrote:
>> >
>> >> because each of the reporting plugins have no concept of how far up the
>> >> lifecycle the build has gone
>> >>
>> >> in maven there are three (3) lifecycles:
>> >>
>> >> 1. the clean lifecycle: pre-clean, clean and post-clean phases
>> >>
>> >> 2: the site lifecycle: pre-site, site and site-deploy
>> >>
>> >> 3. the build lifecycle: validate, ... deploy
>> >>
>> >> mojos have no way to find out which lifecycle they are running, what
>> phase
>> >> they are executing in, and what phases have already executed
>> >>
>> >> thus if you want to report the results of unit tests, you can either:
>> scan
>> >> the filesystem for the results and hope that these results are current;
>> or
>> >> you can fork a build up as far as test and then pull the results from
>> the
>> >> filesystem
>> >>
>> >
>> > [dh] Are you saying that since during reporting surefire has no way to
>> know
>> > if you previously did an install and thus ran the test goal, it will
>> fork a
>> > new build and run the build lifecycle upto test?
>>
>> yes
>>
>> >
>> >>
>> >> then if you want code coverage...
>> >>
>> >> if you want to generate javadocs, you need to fork a build up as far as
>> >> process-sources in order to ensure that the source code has been
>> generated
>> >> before generating the javadocs
>> >>
>> >> if you are a good reporting plugin, you will fork the build
>> >> non-recursive... bad plugins are aggregator plugins that fork a build
>> >> (everything is hunky-dory until you have two forking aggregator plugins
>> in
>> >> the same build, as they will recursively fork each other until you get
>> to a
>> >> leaf project)
>> >>
>> >> 3.x might help solve some of these issues... better still is to switch
>> >> reporting plugins to report, and not to do, and use the build lifecycle
>> for
>> >> doing
>> >>
>> > [dh] ??
>> >
>> >>
>> >> Sent from my [rhymes with tryPod] ;-)
>> >>
>> >>
>> >> On 24 Sep 2009, at 22:18, David Hoffer <dh...@gmail.com> wrote:
>> >>
>> >> We keep having problems with our site-deploy build either hanging or
>> >>> running
>> >>> out of memory. I just noticed that it rebuilds everything about 11
>> times!
>> >>> Why?
>> >>>
>> >>> (This top level pom has 3 modules where those 3 modules each have a
>> few
>> >>> modules. This is the only pom with a reporting section.)
>> >>>
>> >>> Here is our top level reporting section.
>> >>>
>> >>> <reporting>
>> >>> <plugins>
>> >>> <plugin>
>> >>> <groupId>org.codehaus.mojo</groupId>
>> >>> <artifactId>javancss-maven-plugin</artifactId>
>> >>> <version>2.0-beta-2</version>
>> >>> </plugin>
>> >>> <plugin>
>> >>> <groupId>org.codehaus.mojo</groupId>
>> >>> <artifactId>cobertura-maven-plugin</artifactId>
>> >>> <version>${cobertura-maven-plugin.version}</version>
>> >>> </plugin>
>> >>> <plugin>
>> >>> <groupId>org.codehaus.mojo</groupId>
>> >>> <artifactId>surefire-report-maven-plugin</artifactId>
>> >>> <version>2.0-beta-1</version>
>> >>> </plugin>
>> >>> <plugin>
>> >>> <!--Provides creating jar of source-->
>> >>> <groupId>org.apache.maven.plugins</groupId>
>> >>> <artifactId>maven-source-plugin</artifactId>
>> >>> <version>${maven-source-plugin.version}</version>
>> >>> </plugin>
>> >>> <plugin>
>> >>> <groupId>org.apache.maven.plugins</groupId>
>> >>> <artifactId>maven-javadoc-plugin</artifactId>
>> >>> <version>${maven-javadoc-plugin.version}</version>
>> >>> <configuration>
>> >>> <aggregate>true</aggregate>
>> >>> </configuration>
>> >>> </plugin>
>> >>> <plugin>
>> >>> <groupId>org.codehaus.mojo</groupId>
>> >>> <artifactId>jxr-maven-plugin</artifactId>
>> >>> <version>2.0-beta-1</version>
>> >>> </plugin>
>> >>> <plugin>
>> >>> <groupId>org.apache.maven.plugins</groupId>
>> >>> <artifactId>maven-pmd-plugin</artifactId>
>> >>> <version>2.4</version>
>> >>> <configuration>
>> >>> <targetjdk>${jdkVersion}</targetjdk>
>> >>> <rulesets>
>> >>> <ruleset>/rulesets/basic.xml</ruleset>
>> >>> </rulesets>
>> >>> <format>xml</format>
>> >>> <linkXref>true</linkXref>
>> >>> <sourceEncoding>utf-8</sourceEncoding>
>> >>> <minimumTokens>100</minimumTokens>
>> >>> </configuration>
>> >>> </plugin>
>> >>> <plugin>
>> >>> <groupId>org.apache.maven.plugins</groupId>
>> >>>
>> <artifactId>maven-project-info-reports-plugin</artifactId>
>> >>> <version>2.1.1</version>
>> >>> <reportSets>
>> >>> <reportSet>
>> >>> <reports>
>> >>> <report>dependencies</report>
>> >>> <report>dependency-convergence</report>
>> >>> <report>project-team</report>
>> >>> <report>cim</report>
>> >>> <report>license</report>
>> >>> <report>scm</report>
>> >>> <report>index</report>
>> >>> <report>summary</report>
>> >>> </reports>
>> >>> </reportSet>
>> >>> </reportSets>
>> >>> </plugin>
>> >>> </plugins>
>> >>> </reporting>
>> >>>
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> >> For additional commands, e-mail: users-help@maven.apache.org
>> >>
>> >>
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
>
Re: why does site-deploy rebuild so often?
Posted by David Hoffer <dh...@gmail.com>.
Thanks for the explanation that makes sense. I'm surprised maven reporting
is designed so poorly, I agree your approach in the invoker makes more
sense.
BTW, when you say 'fork a build', is this done in the current VM? Is there
a way to force all these in separate VMs?
The problem we have is that as our build gets bigger (they never seem to get
smaller) we are finding that site-deploy is not reliable. Somewhere in the
build it will fail, usually because its out of memory. We have raised the
max heap to about 2GB, max perm gen to about 350k, etc but some piece will
still fail.
Most often it fails using the exec plugin where we need to call into some
Java code. Sometimes the Flex compiler will fail. Etc.
If we could run each of the reports in a separate VM that would solve the
problem, it seems.
What's the best approach for current users of maven to handle this?
I suppose we could generate lots of smaller reports each on a section of the
build, etc, but I'd like to investigate other approaches first.
(BTW, our CI build is on Linux.)
-Dave
On Fri, Sep 25, 2009 at 3:50 AM, Stephen Connolly <
stephen.alan.connolly@gmail.com> wrote:
> 2009/9/25 David Hoffer <dh...@gmail.com>:
> > Hum,
> >
> > Can you restate/finish the last point 'better still is to switch
> reporting
> > plugins to report, and not to do, and use the build lifecycle for doing'?
>
> At the moment, reporting plugins do stuff rather than just generate a
> report of stuff that has already been done.
>
> For example,
>
> the javadoc reporting plugin generates the javadocs... better would be
> to just integrate the already generated javadocs into the site.
>
> the cobertura reporting plugin measures the test coverage... better
> would be to just report the test coverage that was previously measured
> and integrate that report into the site.
>
> Thus reporting plugins would do just that: report
>
> This would keep the reporting lifecycle free from having to fork the
> build lifecycle in order to ensure that the latest results were
> available.
>
> An example of how this works is the maven-invoker-plugin version 1.4,
> where we added a report of the integration tests that have been run.
> That report never forks the build, it just reports on the previous
> results.
>
> With this strategy, you do the work in the build lifecycle... you
> report on the work previously done in the site lifecycle.
>
> > I'm not sure what you are referring to here.
> >
> > Is there a way to know if a reporting plugin is a good or bad one? What
> > about the ones I'm using? I'd say the most important are cobertura,
> > javadocs, findbugs (not shown here).
>
> cobertura forks a build lifecycle
>
> javadocs forks a build lifecycle
>
> not sure about findbugs... but it probably forks a build lifecycle in
> order to ensure that all the source code folders are attached to the
> project model and that any generated source code is generated.
>
> >
> > See below for other comments/questions.
> >
> > -Dave
> >
> >
> > On Thu, Sep 24, 2009 at 3:33 PM, Stephen Connolly <
> > stephen.alan.connolly@gmail.com> wrote:
> >
> >> because each of the reporting plugins have no concept of how far up the
> >> lifecycle the build has gone
> >>
> >> in maven there are three (3) lifecycles:
> >>
> >> 1. the clean lifecycle: pre-clean, clean and post-clean phases
> >>
> >> 2: the site lifecycle: pre-site, site and site-deploy
> >>
> >> 3. the build lifecycle: validate, ... deploy
> >>
> >> mojos have no way to find out which lifecycle they are running, what
> phase
> >> they are executing in, and what phases have already executed
> >>
> >> thus if you want to report the results of unit tests, you can either:
> scan
> >> the filesystem for the results and hope that these results are current;
> or
> >> you can fork a build up as far as test and then pull the results from
> the
> >> filesystem
> >>
> >
> > [dh] Are you saying that since during reporting surefire has no way to
> know
> > if you previously did an install and thus ran the test goal, it will fork
> a
> > new build and run the build lifecycle upto test?
>
> yes
>
> >
> >>
> >> then if you want code coverage...
> >>
> >> if you want to generate javadocs, you need to fork a build up as far as
> >> process-sources in order to ensure that the source code has been
> generated
> >> before generating the javadocs
> >>
> >> if you are a good reporting plugin, you will fork the build
> >> non-recursive... bad plugins are aggregator plugins that fork a build
> >> (everything is hunky-dory until you have two forking aggregator plugins
> in
> >> the same build, as they will recursively fork each other until you get
> to a
> >> leaf project)
> >>
> >> 3.x might help solve some of these issues... better still is to switch
> >> reporting plugins to report, and not to do, and use the build lifecycle
> for
> >> doing
> >>
> > [dh] ??
> >
> >>
> >> Sent from my [rhymes with tryPod] ;-)
> >>
> >>
> >> On 24 Sep 2009, at 22:18, David Hoffer <dh...@gmail.com> wrote:
> >>
> >> We keep having problems with our site-deploy build either hanging or
> >>> running
> >>> out of memory. I just noticed that it rebuilds everything about 11
> times!
> >>> Why?
> >>>
> >>> (This top level pom has 3 modules where those 3 modules each have a few
> >>> modules. This is the only pom with a reporting section.)
> >>>
> >>> Here is our top level reporting section.
> >>>
> >>> <reporting>
> >>> <plugins>
> >>> <plugin>
> >>> <groupId>org.codehaus.mojo</groupId>
> >>> <artifactId>javancss-maven-plugin</artifactId>
> >>> <version>2.0-beta-2</version>
> >>> </plugin>
> >>> <plugin>
> >>> <groupId>org.codehaus.mojo</groupId>
> >>> <artifactId>cobertura-maven-plugin</artifactId>
> >>> <version>${cobertura-maven-plugin.version}</version>
> >>> </plugin>
> >>> <plugin>
> >>> <groupId>org.codehaus.mojo</groupId>
> >>> <artifactId>surefire-report-maven-plugin</artifactId>
> >>> <version>2.0-beta-1</version>
> >>> </plugin>
> >>> <plugin>
> >>> <!--Provides creating jar of source-->
> >>> <groupId>org.apache.maven.plugins</groupId>
> >>> <artifactId>maven-source-plugin</artifactId>
> >>> <version>${maven-source-plugin.version}</version>
> >>> </plugin>
> >>> <plugin>
> >>> <groupId>org.apache.maven.plugins</groupId>
> >>> <artifactId>maven-javadoc-plugin</artifactId>
> >>> <version>${maven-javadoc-plugin.version}</version>
> >>> <configuration>
> >>> <aggregate>true</aggregate>
> >>> </configuration>
> >>> </plugin>
> >>> <plugin>
> >>> <groupId>org.codehaus.mojo</groupId>
> >>> <artifactId>jxr-maven-plugin</artifactId>
> >>> <version>2.0-beta-1</version>
> >>> </plugin>
> >>> <plugin>
> >>> <groupId>org.apache.maven.plugins</groupId>
> >>> <artifactId>maven-pmd-plugin</artifactId>
> >>> <version>2.4</version>
> >>> <configuration>
> >>> <targetjdk>${jdkVersion}</targetjdk>
> >>> <rulesets>
> >>> <ruleset>/rulesets/basic.xml</ruleset>
> >>> </rulesets>
> >>> <format>xml</format>
> >>> <linkXref>true</linkXref>
> >>> <sourceEncoding>utf-8</sourceEncoding>
> >>> <minimumTokens>100</minimumTokens>
> >>> </configuration>
> >>> </plugin>
> >>> <plugin>
> >>> <groupId>org.apache.maven.plugins</groupId>
> >>>
> <artifactId>maven-project-info-reports-plugin</artifactId>
> >>> <version>2.1.1</version>
> >>> <reportSets>
> >>> <reportSet>
> >>> <reports>
> >>> <report>dependencies</report>
> >>> <report>dependency-convergence</report>
> >>> <report>project-team</report>
> >>> <report>cim</report>
> >>> <report>license</report>
> >>> <report>scm</report>
> >>> <report>index</report>
> >>> <report>summary</report>
> >>> </reports>
> >>> </reportSet>
> >>> </reportSets>
> >>> </plugin>
> >>> </plugins>
> >>> </reporting>
> >>>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> >> For additional commands, e-mail: users-help@maven.apache.org
> >>
> >>
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
Re: why does site-deploy rebuild so often?
Posted by Stephen Connolly <st...@gmail.com>.
2009/9/25 David Hoffer <dh...@gmail.com>:
> Hum,
>
> Can you restate/finish the last point 'better still is to switch reporting
> plugins to report, and not to do, and use the build lifecycle for doing'?
At the moment, reporting plugins do stuff rather than just generate a
report of stuff that has already been done.
For example,
the javadoc reporting plugin generates the javadocs... better would be
to just integrate the already generated javadocs into the site.
the cobertura reporting plugin measures the test coverage... better
would be to just report the test coverage that was previously measured
and integrate that report into the site.
Thus reporting plugins would do just that: report
This would keep the reporting lifecycle free from having to fork the
build lifecycle in order to ensure that the latest results were
available.
An example of how this works is the maven-invoker-plugin version 1.4,
where we added a report of the integration tests that have been run.
That report never forks the build, it just reports on the previous
results.
With this strategy, you do the work in the build lifecycle... you
report on the work previously done in the site lifecycle.
> I'm not sure what you are referring to here.
>
> Is there a way to know if a reporting plugin is a good or bad one? What
> about the ones I'm using? I'd say the most important are cobertura,
> javadocs, findbugs (not shown here).
cobertura forks a build lifecycle
javadocs forks a build lifecycle
not sure about findbugs... but it probably forks a build lifecycle in
order to ensure that all the source code folders are attached to the
project model and that any generated source code is generated.
>
> See below for other comments/questions.
>
> -Dave
>
>
> On Thu, Sep 24, 2009 at 3:33 PM, Stephen Connolly <
> stephen.alan.connolly@gmail.com> wrote:
>
>> because each of the reporting plugins have no concept of how far up the
>> lifecycle the build has gone
>>
>> in maven there are three (3) lifecycles:
>>
>> 1. the clean lifecycle: pre-clean, clean and post-clean phases
>>
>> 2: the site lifecycle: pre-site, site and site-deploy
>>
>> 3. the build lifecycle: validate, ... deploy
>>
>> mojos have no way to find out which lifecycle they are running, what phase
>> they are executing in, and what phases have already executed
>>
>> thus if you want to report the results of unit tests, you can either: scan
>> the filesystem for the results and hope that these results are current; or
>> you can fork a build up as far as test and then pull the results from the
>> filesystem
>>
>
> [dh] Are you saying that since during reporting surefire has no way to know
> if you previously did an install and thus ran the test goal, it will fork a
> new build and run the build lifecycle upto test?
yes
>
>>
>> then if you want code coverage...
>>
>> if you want to generate javadocs, you need to fork a build up as far as
>> process-sources in order to ensure that the source code has been generated
>> before generating the javadocs
>>
>> if you are a good reporting plugin, you will fork the build
>> non-recursive... bad plugins are aggregator plugins that fork a build
>> (everything is hunky-dory until you have two forking aggregator plugins in
>> the same build, as they will recursively fork each other until you get to a
>> leaf project)
>>
>> 3.x might help solve some of these issues... better still is to switch
>> reporting plugins to report, and not to do, and use the build lifecycle for
>> doing
>>
> [dh] ??
>
>>
>> Sent from my [rhymes with tryPod] ;-)
>>
>>
>> On 24 Sep 2009, at 22:18, David Hoffer <dh...@gmail.com> wrote:
>>
>> We keep having problems with our site-deploy build either hanging or
>>> running
>>> out of memory. I just noticed that it rebuilds everything about 11 times!
>>> Why?
>>>
>>> (This top level pom has 3 modules where those 3 modules each have a few
>>> modules. This is the only pom with a reporting section.)
>>>
>>> Here is our top level reporting section.
>>>
>>> <reporting>
>>> <plugins>
>>> <plugin>
>>> <groupId>org.codehaus.mojo</groupId>
>>> <artifactId>javancss-maven-plugin</artifactId>
>>> <version>2.0-beta-2</version>
>>> </plugin>
>>> <plugin>
>>> <groupId>org.codehaus.mojo</groupId>
>>> <artifactId>cobertura-maven-plugin</artifactId>
>>> <version>${cobertura-maven-plugin.version}</version>
>>> </plugin>
>>> <plugin>
>>> <groupId>org.codehaus.mojo</groupId>
>>> <artifactId>surefire-report-maven-plugin</artifactId>
>>> <version>2.0-beta-1</version>
>>> </plugin>
>>> <plugin>
>>> <!--Provides creating jar of source-->
>>> <groupId>org.apache.maven.plugins</groupId>
>>> <artifactId>maven-source-plugin</artifactId>
>>> <version>${maven-source-plugin.version}</version>
>>> </plugin>
>>> <plugin>
>>> <groupId>org.apache.maven.plugins</groupId>
>>> <artifactId>maven-javadoc-plugin</artifactId>
>>> <version>${maven-javadoc-plugin.version}</version>
>>> <configuration>
>>> <aggregate>true</aggregate>
>>> </configuration>
>>> </plugin>
>>> <plugin>
>>> <groupId>org.codehaus.mojo</groupId>
>>> <artifactId>jxr-maven-plugin</artifactId>
>>> <version>2.0-beta-1</version>
>>> </plugin>
>>> <plugin>
>>> <groupId>org.apache.maven.plugins</groupId>
>>> <artifactId>maven-pmd-plugin</artifactId>
>>> <version>2.4</version>
>>> <configuration>
>>> <targetjdk>${jdkVersion}</targetjdk>
>>> <rulesets>
>>> <ruleset>/rulesets/basic.xml</ruleset>
>>> </rulesets>
>>> <format>xml</format>
>>> <linkXref>true</linkXref>
>>> <sourceEncoding>utf-8</sourceEncoding>
>>> <minimumTokens>100</minimumTokens>
>>> </configuration>
>>> </plugin>
>>> <plugin>
>>> <groupId>org.apache.maven.plugins</groupId>
>>> <artifactId>maven-project-info-reports-plugin</artifactId>
>>> <version>2.1.1</version>
>>> <reportSets>
>>> <reportSet>
>>> <reports>
>>> <report>dependencies</report>
>>> <report>dependency-convergence</report>
>>> <report>project-team</report>
>>> <report>cim</report>
>>> <report>license</report>
>>> <report>scm</report>
>>> <report>index</report>
>>> <report>summary</report>
>>> </reports>
>>> </reportSet>
>>> </reportSets>
>>> </plugin>
>>> </plugins>
>>> </reporting>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: why does site-deploy rebuild so often?
Posted by David Hoffer <dh...@gmail.com>.
Hum,
Can you restate/finish the last point 'better still is to switch reporting
plugins to report, and not to do, and use the build lifecycle for doing'?
I'm not sure what you are referring to here.
Is there a way to know if a reporting plugin is a good or bad one? What
about the ones I'm using? I'd say the most important are cobertura,
javadocs, findbugs (not shown here).
See below for other comments/questions.
-Dave
On Thu, Sep 24, 2009 at 3:33 PM, Stephen Connolly <
stephen.alan.connolly@gmail.com> wrote:
> because each of the reporting plugins have no concept of how far up the
> lifecycle the build has gone
>
> in maven there are three (3) lifecycles:
>
> 1. the clean lifecycle: pre-clean, clean and post-clean phases
>
> 2: the site lifecycle: pre-site, site and site-deploy
>
> 3. the build lifecycle: validate, ... deploy
>
> mojos have no way to find out which lifecycle they are running, what phase
> they are executing in, and what phases have already executed
>
> thus if you want to report the results of unit tests, you can either: scan
> the filesystem for the results and hope that these results are current; or
> you can fork a build up as far as test and then pull the results from the
> filesystem
>
[dh] Are you saying that since during reporting surefire has no way to know
if you previously did an install and thus ran the test goal, it will fork a
new build and run the build lifecycle upto test?
>
> then if you want code coverage...
>
> if you want to generate javadocs, you need to fork a build up as far as
> process-sources in order to ensure that the source code has been generated
> before generating the javadocs
>
> if you are a good reporting plugin, you will fork the build
> non-recursive... bad plugins are aggregator plugins that fork a build
> (everything is hunky-dory until you have two forking aggregator plugins in
> the same build, as they will recursively fork each other until you get to a
> leaf project)
>
> 3.x might help solve some of these issues... better still is to switch
> reporting plugins to report, and not to do, and use the build lifecycle for
> doing
>
[dh] ??
>
> Sent from my [rhymes with tryPod] ;-)
>
>
> On 24 Sep 2009, at 22:18, David Hoffer <dh...@gmail.com> wrote:
>
> We keep having problems with our site-deploy build either hanging or
>> running
>> out of memory. I just noticed that it rebuilds everything about 11 times!
>> Why?
>>
>> (This top level pom has 3 modules where those 3 modules each have a few
>> modules. This is the only pom with a reporting section.)
>>
>> Here is our top level reporting section.
>>
>> <reporting>
>> <plugins>
>> <plugin>
>> <groupId>org.codehaus.mojo</groupId>
>> <artifactId>javancss-maven-plugin</artifactId>
>> <version>2.0-beta-2</version>
>> </plugin>
>> <plugin>
>> <groupId>org.codehaus.mojo</groupId>
>> <artifactId>cobertura-maven-plugin</artifactId>
>> <version>${cobertura-maven-plugin.version}</version>
>> </plugin>
>> <plugin>
>> <groupId>org.codehaus.mojo</groupId>
>> <artifactId>surefire-report-maven-plugin</artifactId>
>> <version>2.0-beta-1</version>
>> </plugin>
>> <plugin>
>> <!--Provides creating jar of source-->
>> <groupId>org.apache.maven.plugins</groupId>
>> <artifactId>maven-source-plugin</artifactId>
>> <version>${maven-source-plugin.version}</version>
>> </plugin>
>> <plugin>
>> <groupId>org.apache.maven.plugins</groupId>
>> <artifactId>maven-javadoc-plugin</artifactId>
>> <version>${maven-javadoc-plugin.version}</version>
>> <configuration>
>> <aggregate>true</aggregate>
>> </configuration>
>> </plugin>
>> <plugin>
>> <groupId>org.codehaus.mojo</groupId>
>> <artifactId>jxr-maven-plugin</artifactId>
>> <version>2.0-beta-1</version>
>> </plugin>
>> <plugin>
>> <groupId>org.apache.maven.plugins</groupId>
>> <artifactId>maven-pmd-plugin</artifactId>
>> <version>2.4</version>
>> <configuration>
>> <targetjdk>${jdkVersion}</targetjdk>
>> <rulesets>
>> <ruleset>/rulesets/basic.xml</ruleset>
>> </rulesets>
>> <format>xml</format>
>> <linkXref>true</linkXref>
>> <sourceEncoding>utf-8</sourceEncoding>
>> <minimumTokens>100</minimumTokens>
>> </configuration>
>> </plugin>
>> <plugin>
>> <groupId>org.apache.maven.plugins</groupId>
>> <artifactId>maven-project-info-reports-plugin</artifactId>
>> <version>2.1.1</version>
>> <reportSets>
>> <reportSet>
>> <reports>
>> <report>dependencies</report>
>> <report>dependency-convergence</report>
>> <report>project-team</report>
>> <report>cim</report>
>> <report>license</report>
>> <report>scm</report>
>> <report>index</report>
>> <report>summary</report>
>> </reports>
>> </reportSet>
>> </reportSets>
>> </plugin>
>> </plugins>
>> </reporting>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
Re: why does site-deploy rebuild so often?
Posted by Stephen Connolly <st...@gmail.com>.
because each of the reporting plugins have no concept of how far up
the lifecycle the build has gone
in maven there are three (3) lifecycles:
1. the clean lifecycle: pre-clean, clean and post-clean phases
2: the site lifecycle: pre-site, site and site-deploy
3. the build lifecycle: validate, ... deploy
mojos have no way to find out which lifecycle they are running, what
phase they are executing in, and what phases have already executed
thus if you want to report the results of unit tests, you can either:
scan the filesystem for the results and hope that these results are
current; or you can fork a build up as far as test and then pull the
results from the filesystem
then if you want code coverage...
if you want to generate javadocs, you need to fork a build up as far
as process-sources in order to ensure that the source code has been
generated before generating the javadocs
if you are a good reporting plugin, you will fork the build non-
recursive... bad plugins are aggregator plugins that fork a build
(everything is hunky-dory until you have two forking aggregator
plugins in the same build, as they will recursively fork each other
until you get to a leaf project)
3.x might help solve some of these issues... better still is to switch
reporting plugins to report, and not to do, and use the build
lifecycle for doing
Sent from my [rhymes with tryPod] ;-)
On 24 Sep 2009, at 22:18, David Hoffer <dh...@gmail.com> wrote:
> We keep having problems with our site-deploy build either hanging or
> running
> out of memory. I just noticed that it rebuilds everything about 11
> times!
> Why?
>
> (This top level pom has 3 modules where those 3 modules each have a
> few
> modules. This is the only pom with a reporting section.)
>
> Here is our top level reporting section.
>
> <reporting>
> <plugins>
> <plugin>
> <groupId>org.codehaus.mojo</groupId>
> <artifactId>javancss-maven-plugin</artifactId>
> <version>2.0-beta-2</version>
> </plugin>
> <plugin>
> <groupId>org.codehaus.mojo</groupId>
> <artifactId>cobertura-maven-plugin</artifactId>
> <version>${cobertura-maven-plugin.version}</version>
> </plugin>
> <plugin>
> <groupId>org.codehaus.mojo</groupId>
> <artifactId>surefire-report-maven-plugin</artifactId>
> <version>2.0-beta-1</version>
> </plugin>
> <plugin>
> <!--Provides creating jar of source-->
> <groupId>org.apache.maven.plugins</groupId>
> <artifactId>maven-source-plugin</artifactId>
> <version>${maven-source-plugin.version}</version>
> </plugin>
> <plugin>
> <groupId>org.apache.maven.plugins</groupId>
> <artifactId>maven-javadoc-plugin</artifactId>
> <version>${maven-javadoc-plugin.version}</version>
> <configuration>
> <aggregate>true</aggregate>
> </configuration>
> </plugin>
> <plugin>
> <groupId>org.codehaus.mojo</groupId>
> <artifactId>jxr-maven-plugin</artifactId>
> <version>2.0-beta-1</version>
> </plugin>
> <plugin>
> <groupId>org.apache.maven.plugins</groupId>
> <artifactId>maven-pmd-plugin</artifactId>
> <version>2.4</version>
> <configuration>
> <targetjdk>${jdkVersion}</targetjdk>
> <rulesets>
> <ruleset>/rulesets/basic.xml</ruleset>
> </rulesets>
> <format>xml</format>
> <linkXref>true</linkXref>
> <sourceEncoding>utf-8</sourceEncoding>
> <minimumTokens>100</minimumTokens>
> </configuration>
> </plugin>
> <plugin>
> <groupId>org.apache.maven.plugins</groupId>
> <artifactId>maven-project-info-reports-plugin</
> artifactId>
> <version>2.1.1</version>
> <reportSets>
> <reportSet>
> <reports>
> <report>dependencies</report>
> <report>dependency-convergence</report>
> <report>project-team</report>
> <report>cim</report>
> <report>license</report>
> <report>scm</report>
> <report>index</report>
> <report>summary</report>
> </reports>
> </reportSet>
> </reportSets>
> </plugin>
> </plugins>
> </reporting>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org