Maven Surefire

Aggregate report is empty for multi-module project

Details

  • Type: Bug Bug
  • Status: Open Open
  • Priority: Minor Minor
  • Resolution: Unresolved
  • Affects Version/s: 2.7.1
  • Fix Version/s: None
  • Component/s: Maven Surefire Report Plugin
  • Labels:
    None
  • Environment:
    Maven 3.0.1, Site 3.0-beta-3, Windows XP SP3
  • Complexity:
    Intermediate
  • Number of attachments :
    1

Description

The parent project has a site configuration with an aggregated surefire report and inherited set to false. The child module has one test.

Problem: "mvn clean; mvn site-deploy" creates a surefire report with zero tests. With 2.7.2-SNAPSHOT as of today the problem is the same.

Why does the surefire report plugin not immediately descend to the child modules, compile and test them while executing the aggregate report for the parent module?

The problem seems to be that the aggregate surefire report for the parent is generated but the surefire plugin doesn't run the tests for the child modules before. So the aggregate surefire report doesn't find any surefire test results for the child modules.

If I run "mvn clean test; mvn site-deploy", the resulting aggregate surefire report is correct. The reason is probably that the site-deploy collects the surefire results for the child modules from the previous run.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Kristian Rosenvold added a comment -

Thanks for creating a separate issue for this, which is much better than piggybacking onto a slightly different issue (SUREFIRE-666). I will try to fix this for 2.7.3

Show
Kristian Rosenvold added a comment - Thanks for creating a separate issue for this, which is much better than piggybacking onto a slightly different issue ( SUREFIRE-666 ). I will try to fix this for 2.7.3
Hide
Permalink
Jim McIver added a comment -

Hi - Do you have any timescale for this fix ? It's causing me some problems not being able to get an aggregated, project-level surefire report. Thanks, Jim

Show
Jim McIver added a comment - Hi - Do you have any timescale for this fix ? It's causing me some problems not being able to get an aggregated, project-level surefire report. Thanks, Jim
Hide
Permalink
Stephen Connolly added a comment -

Part of the issue is that the general consensus is that having reporting mojo's fork a lifecycle is a really bad plan, hence why the report-only mojo's have been introduced... perhaps we should deprecate the report mojo to explain.

In other words, the aggregate report should be empty unless you have invoked a lifecycle up as far as test previously... in fact if your project requires, for example a war from a dependent module, the current fork only as far as "test" will result in failures as the war will not have been packaged.

I am tempted to say the fix for this is to deprecate the "report" mojo and force everyone to invoke the lifecycle before building the site.... but that seems very harsh to do in a point release, and certainly too harsh to do without a vote on dev@maven first.

Kristian, I will leave the decision up to you

Show
Stephen Connolly added a comment - Part of the issue is that the general consensus is that having reporting mojo's fork a lifecycle is a really bad plan, hence why the report-only mojo's have been introduced... perhaps we should deprecate the report mojo to explain. In other words, the aggregate report should be empty unless you have invoked a lifecycle up as far as test previously... in fact if your project requires, for example a war from a dependent module, the current fork only as far as "test" will result in failures as the war will not have been packaged. I am tempted to say the fix for this is to deprecate the "report" mojo and force everyone to invoke the lifecycle before building the site.... but that seems very harsh to do in a point release, and certainly too harsh to do without a vote on dev@maven first. Kristian, I will leave the decision up to you
Hide
Permalink
Kristian Rosenvold added a comment -

I think adding some docs on this one is probably the "best" thing to do

Show
Kristian Rosenvold added a comment - I think adding some docs on this one is probably the "best" thing to do

People

  • Assignee:
    Unassigned
    Reporter:
    Martin Ackermann
Vote (2)
Watch (3)

Dates

  • Created:
    Updated: