<!--IssueSummary start--> <details> <summary> Everyone can contribute. [Help move this issue forward](https://handbook.gitlab.com/handbook/marketing/developer-relations/contributor-success/community-contributors-workflows/#contributor-links) while earning points, leveling up and collecting rewards. </summary> - [Close this issue](https://contributors.gitlab.com/manage-issue?action=close&projectId=278964&issueIid=491015) </details> <!--IssueSummary end--> <!-- This template is a great use for issues that are feature::additions or technical tasks for larger issues.--> ### Proposal <!-- Use this section to explain the feature and how it will work. It can be helpful to add technical details, design proposals, and links to related epics or issues. --> <!-- Consider adding related issues and epics to this issue. You can also reference the Feature Proposal Template (https://gitlab.com/gitlab-org/gitlab/-/blob/master/.gitlab/issue_templates/Feature%20proposal%20-%20detailed.md) for additional details to consider adding to this issue. Additionally, as a data oriented organization, when your feature exits planning breakdown, consider adding the `What does success look like, and how can we measure that?` section. --> <!-- Label reminders Use the following resources to find the appropriate labels: - Use only one tier label choosing the lowest tier this is intended for - https://gitlab.com/gitlab-org/gitlab/-/labels - https://about.gitlab.com/handbook/product/categories/features/ --> Add support for JaCoCo aggregated reports in test coverage visualization. Follows https://gitlab.com/gitlab-org/gitlab/-/issues/227345 (and mentionned in https://gitlab.com/gitlab-org/gitlab/-/issues/479804#note_2116912208). The current process works great in multi module projects if there are multiple JaCoCo reports, one in each module (see https://gitlab.com/gitlab-org/gitlab/-/issues/227345#note_2059938471). - `module1` - `target/jacoco-report/jacoco.xml` - `module2` - `target/jacoco-report/jacoco.xml` --- For my projects, I have a different architecture. I have a `report` module that aggregate reports into a single one. - `module1` - `module2` - `report` (includes `module1` and `module2`) - `target/jacoco-report/jacoco.xml` The HTML report looks like this:  ### Reproducer See project https://gitlab.com/jdussouillez/gitlab-jacoco-report-aggregate - [PR #1](https://gitlab.com/jdussouillez/gitlab-jacoco-report-aggregate/-/merge_requests/1/diffs): Test coverage visualization doesn't work because I use the aggregated report. [code](https://gitlab.com/jdussouillez/gitlab-jacoco-report-aggregate/-/merge_requests/1/diffs#587d266bb27a4dc3022bbed44dfa19849df3044c_26_27)  - [PR #2](https://gitlab.com/jdussouillez/gitlab-jacoco-report-aggregate/-/merge_requests/2/diffs): Test coverage visualization works because I use both `module1` and `module2` reports and not the one aggregated. [code](https://gitlab.com/jdussouillez/gitlab-jacoco-report-aggregate/-/merge_requests/2/diffs#587d266bb27a4dc3022bbed44dfa19849df3044c_27_27)  ### Reports Here the structure of a report for a single module: ```xml <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE report PUBLIC "-//JACOCO//DTD Report 1.1//EN" "report.dtd"> <report name="myapp-module1"> <package name="com/gitlab/jdussouillez/module1"> <!-- [...] --> </package> <!-- [...] --> </report> ``` And for an aggregate: ```xml <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE report PUBLIC "-//JACOCO//DTD Report 1.1//EN" "report.dtd"> <report name="myapp"> <group name="myapp-module1"> <package name="com/gitlab/jdussouillez/module1"> <!-- [...] --> </package> <!-- [...] --> </group> <group name="myapp-module2"> <package name="com/gitlab/jdussouillez/module2"> <!-- [...] --> </package> <!-- [...] --> </group> <!-- [...] --> </report> ``` ## Implementation Guide **Cases to handle** * If the `<group>` tag's `name` attr always contains the root dir's name, e.g. the directory names at the root of your project `myapp-module1`, `myapp-module2`,it allows us to infer the file in the edge case of having 2 files with identical paths, aside from their root dirs. e.g. `module-1/src/main/java/com/gitlab/jdussouillez/acme`, `my-app-module-2/src/main/java/com/gitlab/jdussouillez/acme` * If the `<group>` tag's `name` attr doesn't contain the root dir's name, we can't support the above case and it will be a limitation to add to the docs. We need to confirm with the JaCoCo maintainers if the `group` can be customized and if it is always populated when using the `report-aggregate` goal on the maven config. ### Resources - [JaCoCo - report-aggregate](https://www.eclemma.org/jacoco/trunk/doc/report-aggregate-mojo.html)