[
http://jira.codehaus.org/browse/SUREFIRE-348?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brett Porter updated SUREFIRE-348:
----------------------------------
Fix Version/s: 2.x
> 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
> Fix For: 2.x
>
>
> 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
