You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@maven.apache.org by "Dan Fabulich (JIRA)" <ji...@codehaus.org> on 2007/11/26 10:04:57 UTC
[jira] Closed: (SUREFIRE-348) Proivde a surefire aggregate option
for report-only mojo
[ http://jira.codehaus.org/browse/SUREFIRE-348?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Dan Fabulich closed SUREFIRE-348.
---------------------------------
Resolution: Duplicate
Fix Version/s: (was: 2.x)
Duplicate of SUREFIRE-268, which is now fixed. (I did continue with the assumptions present in javadoc and jxr, sorry.)
> Proivde a surefire aggregate option for report-only mojo
> --------------------------------------------------------
>
> Key: SUREFIRE-348
> URL: http://jira.codehaus.org/browse/SUREFIRE-348
> Project: Maven Surefire
> Issue Type: New Feature
> Components: report plugin
> Affects Versions: 2.3
> Reporter: John Allen
>
> I have recently modified many plugins to provide aggregate features that aggregate their respective reports for contained sub-n-modules (inc. sub-sub etc) up the *module* hierarchy (ie not inheritance hierarchy that may be unrelated to the reactor and module structure) and would like to see this for surefire. This enables use view reports for various levels of sub-systems resulting in top level reports that cover an entire solution.
> I would like to request this feature for the report-only mojo (god knows how you;d do it for the forking surefire:report one)
> My recommendation is either to separate aggregate into a separate mojo that pulls the surefire result xml files up the tree, merging them as it goes and then have report-only simply knock out a report for the, now aggregated report files it finds when its run as part of site. With is the site generation model one binds these kinds of site preprocessing mojos, that themselves tend to be able to @aggregatorrs (thus also getting round the bug where reporting mojos cant be aggregators) to the pre-site phase. This is our preferred technique to site building where one treats analysis a part of the normal build lifecycle (for how else would one be able to run checkers that read the analysis and fail the build if thresholds are breached?) and reporting do nothing but report on the data that has been produced by the normal build and analysis phases (ie no evil forked lifecycles).
> The alternative is to pull the data up to the scope that the report-only mojo is running at from the sub-n-modules beneath it before it then reports on it. The mojo obviously gets run for each level of the module hierarchy as the reactor is processed. This can be optimised to do all the work at the top most module if one wants - i.e. build the merged aggregated data files for all the sub-modules on those modules behalf, as it builds its top-most aggregated data file (ie it populates sub-module target/surefire directories with their merged report xml for them as it needs this info for its report).
> Note I do not know (or like) why the assumptions present in Javadoc and JXR that if one want to aggregate one only wants to aggregate to the top most project..
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira