[ https://issues.apache.org/jira/browse/SUREFIRE-2004?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17516425#comment-17516425 ]
Alexander Kriegisch edited comment on SUREFIRE-2004 at 4/3/22 4:53 AM: ----------------------------------------------------------------------- [~tibordigana], I understand [~gzm55]'s question, because Surefire release cycles are quite long. I quickly checked on Maven Central: The first Surefire 3 milestone was released in November 2018, i.e. ~3.5 years ago. The current milestone 5 was released in June 2020, almost 2 years ago. I myself have been using self-built releases since M5, because bugs were either not fixed or after being fixed there was no non-snapshot release. I fully understand that everyone involved in Surefire is doing their best, working for free and in their spare time. But from a user perspective, these "milestones" take longer than major or at least minor releases in some other projects. Even a giant like Java has a 6 month release cadence. Would you mind taking this topic into your next meeting or written exchange with your co-developers and explore options to release more often? Even small bugfix or feature releases would take some pressure off of both the dev team and the user community. was (Author: kriegaex): [~tibordigana], I understand [~gzm55]'s question, because Surefire release cycles are quite long. I quickly checked on Maven Central: The first Surefire 3 milestone was released in November 2018, i.e. ~3.5 years ago. The current milestone 5 was released in June 2020, almost 2 years ago. I myself have been using self-built releases since M5, because bugs were either not fixed or after being fixed there was no non-snapshot release. I fully understand that everyone involved in Surefire is doing their best, working for free and in their sparetime. But from a user perspective, these "milestones" take longer than major or at least minor releases in some other projects. Even a giant like Java has a 6 month release cadence. Would you mind taking this topic into your next meeting or written exchange with your co-developers and explore options to release more often? Even small bugfix or feature releases would take some pressure off of both the dev team and the user community. > 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 > Fix For: waiting-for-apache-feedback > > > 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)