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]
