Maven Surefire
  1. Maven Surefire
  2. SUREFIRE-688

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
    • 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

        Martin Ackermann made changes -
        Field Original Value New Value
        Attachment trial-maven.zip [ 53291 ]
        Hide
        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
        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
        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
        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
          • Votes:
            3 Vote for this issue
            Watchers:
            4 Start watching this issue

            Dates

            • Created:
              Updated: