[ https://issues.apache.org/jira/browse/SUREFIRE-2004?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17515778#comment-17515778 ]
Alexander Kriegisch commented on SUREFIRE-2004: ----------------------------------------------- [~tibordigana], I am not sure if you were asking me or James for a reproducible project. But actually, it is super trivial: Just use any single-module JAR project and activate the aggregation option. > Empty report for single-module project with 'aggregate=true' > ------------------------------------------------------------ > > Key: SUREFIRE-2004 > URL: https://issues.apache.org/jira/browse/SUREFIRE-2004 > Project: Maven Surefire > Issue Type: Bug > Components: Maven Surefire Report Plugin > Affects Versions: 2.4, 3.0.0-M5 > Reporter: Alexander Kriegisch > Priority: Major > > Using either {{-Daggregate=true}} on CLI or {{<aggregate>true</aggregate>}} > in the plugin configuration leads to an empty report (i.e. zero tests > reported) when e.g. executing > {code:none} > mvn -Dmaven.test.failure.ignore=true -Daggregate=true clean verify > surefire-report:report-only > {code} > in the context of a single-module project. As soon as I make the root module > pom-packaged and move the tests to into a child module, the aggregate report > works. > FYI, if I do not define the plugin and its version in my POM at all, the > default version 2.4 used by Maven on my workstation has the same problem, so > this does not seem to be a 3.0.0-M5 issue only. > ---- > Background info about how and why I actually stumbled across this problem: I > have an OSS multi-module project with lots of expensive UI tests. The full > build can take 2.5 hours. I wanted to test a few CLI settings before creating > an additional GitHub CI build workflow which can be run on demand and always > runs all tests in all modules (ignoring errors and failures), no matter what. > In the end, it is supposed to create a single-file aggregate HTML report > which can easily be attached to the build and later is available for > download, if the user so chooses in order to analyse failing tests > comfortable and without having to scroll through build logs. You get the > picture, I guess. In the original project, there is a pom-packaged root POM, > so the problem described in this issue does not occur there. I simply created > a single-module dummy project in order to verify the effect of certain build > options quickly and not having to wait for the slow original build to finish. > Eventually, I noticed the issue described above. -- This message was sent by Atlassian Jira (v8.20.1#820001)