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 <dhoff...@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.conno...@gmail.com> wrote:
>
>> 2009/9/25 David Hoffer <dhoff...@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.conno...@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 <dhoff...@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-unsubscr...@maven.apache.org
>> >> For additional commands, e-mail: users-h...@maven.apache.org
>> >>
>> >>
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>> For additional commands, e-mail: users-h...@maven.apache.org
>>
>>
>
