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 <[email protected]>: > 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 <[email protected]> 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 < >> [email protected]> wrote: >> >>> 2009/9/25 David Hoffer <[email protected]>: >>> > 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 < >>> > [email protected]> 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 <[email protected]> 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: [email protected] >>> >> For additional commands, e-mail: [email protected] >>> >> >>> >> >>> > >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [email protected] >>> For additional commands, e-mail: [email protected] >>> >>> >> > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
