[
https://issues.apache.org/jira/browse/SUREFIRE-2004?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17488654#comment-17488654
]
Alexander Kriegisch edited comment on SUREFIRE-2004 at 2/8/22, 8:03 AM:
------------------------------------------------------------------------
{quote}It does not say and does not mean that it aggregates reports accross
Maven modules.{quote}
But that is exactly what it does. *It aggregates reports from multiple modules
into one,* also merging packages and test classes into a single list. So far,
so good. So it is just about aggregating Surefire + Failsafe into one report.
I did not even try if it does. I know 100% that it does what I described,
because I am using it this way.
So far, so good. Like I said, the main problem is that the special case for
{{n}} modules with {{n ==1}} is what is not working, probably because the
plugin cannot handle the case that the root is not just a place to aggregate
something from other modules, but also can contain a report itself (if it is
jar-packaged), which in this case simply means that the plugin also has to
search for test reports to aggregate in its own build directory. That is
actually quite simple.
Please let us not talk about JaCoCo or other plugins, I am talking about
Surefire Reports. Never having tested those plugins for this scenario, I cannot
say anything intelligent about how they behave when told to aggregate something
for a single-module project. But I would assume that they know how to handle
this special case, because it makes sense.
was (Author: kriegaex):
{quote}It does not say and does not mean that it aggregates reports accross
Maven modules.{quote}
But that is exactly what it does. It aggregates reports from multiple modules
into one, also merging packages and test classes into a single list. So far, so
good. So it is just about aggregating Surefire + Failsafe into one report. I
did not even try if it does. I know 100% that it does what I described, because
I am using it this way.
So far, so good. Like I said, the main problem is that the special case for
{{n}} modules with {{n ==1}} is what is not working, probably because the
plugin cannot handle the case that the root is not just a place to aggregate
something from other modules, but also can contain a report itself (if it is
jar-packaged), which in this case simply means that the plugin also has to
search for test reports to aggregate in its own build directory. That is
actually quite simple.
Please let us not talk about JaCoCo or other plugins, I am talking about
Surefire Reports. Never having tested those plugins for this scenario, I cannot
say anything intelligent about how they behave when told to aggregate something
for a single-module project. But I would assume that they know how to handle
this special case, because it makes sense.
> 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)
