Source path is not stored in report XML

9 views
Skip to first unread message

Ullrich Hafner

unread,
Nov 24, 2021, 5:04:57 AM11/24/21
to JaCoCo and EclEmma Users
I'm currently trying to improve the visualization of JaCoCo reports in Jenkins (https://github.com/jenkinsci/code-coverage-api-plugin/). The plugin reads a JaCoCo XML report and shows the details in Jenkins. While parsing the JaCoCo XML reports I noticed that packages (and so classes) are qualified only by the actual package path that starts right after the *source code path*. I.e., `package="/io/jenkins/"` and not `package="src/main/java/io/jenkins/"` or `package="/absolute/path/to/io/jenkins/"`. Is there a way to include the source code path in the XML file as well (or use the absolute path)? Otherwise I need to guess where the actual source code is stored (or I need to duplicate the JaCoCo option of specifying a source code path manually). 

Marc Hoffmann

unread,
Nov 24, 2021, 6:45:14 AM11/24/21
to JaCoCo and EclEmma Users
Hi,

the JaCoCo xml report is created without using source code. For this report we actually don’t know where the source code is neither. The source code is only loaded for the HTML report.

Cheers,
-marc

On 24. Nov 2021, at 11:04, Ullrich Hafner <ullrich...@gmail.com> wrote:

I'm currently trying to improve the visualization of JaCoCo reports in Jenkins (https://github.com/jenkinsci/code-coverage-api-plugin/). The plugin reads a JaCoCo XML report and shows the details in Jenkins. While parsing the JaCoCo XML reports I noticed that packages (and so classes) are qualified only by the actual package path that starts right after the *source code path*. I.e., `package="/io/jenkins/"` and not `package="src/main/java/io/jenkins/"` or `package="/absolute/path/to/io/jenkins/"`. Is there a way to include the source code path in the XML file as well (or use the absolute path)? Otherwise I need to guess where the actual source code is stored (or I need to duplicate the JaCoCo option of specifying a source code path manually). 

--
You received this message because you are subscribed to the Google Groups "JaCoCo and EclEmma Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jacoco+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jacoco/88cfbbd8-72cd-4b02-868f-8b4e974ec003n%40googlegroups.com.

Ullrich Hafner

unread,
Nov 25, 2021, 2:45:18 AM11/25/21
to jac...@googlegroups.com
I see. I understand that technically the source code path is not required but from a users perspective wouldn’t it be helpful (for all other report consumers) if the actual source path would be added to the XML file in the HTML report step? Cobertura adds that path and most of the static analysis tools that work on class files (e.g. SpotBugs) do it as well. This would simplify things for those tools that work right after the coverage report generation.  

Marc Hoffmann

unread,
Nov 25, 2021, 3:49:16 AM11/25/21
to jac...@googlegroups.com
Hi,

the tools you’re mentioning work on source code and need source code as an import anyways.

These new source attributes would have to be configured by the user anyways. We do this already for the HTML report but basically use lookup paths to find specific source files. Your example with packages will probably not work as due to split-packages (think of main/test) there is not a single location for a package.

Regards,
-marc



Ullrich Hafner

unread,
Nov 25, 2021, 8:57:32 AM11/25/21
to jac...@googlegroups.com
Am 25.11.2021 um 09:49 schrieb Marc Hoffmann <hoff...@mountainminds.com>:

Hi,

the tools you’re mentioning work on source code and need source code as an import anyways.


Cobertura and SpotBugs are both working on the byte code as well (as far as I know). The source code is only used to improve their reports (as you are doing in your HTML report) with exact source code locations.

These new source attributes would have to be configured by the user anyways. We do this already for the HTML report but basically use lookup paths to find specific source files.

Ok, that is what I need to implement then as well. I hoped that I (and my users) can get around that part as it could be done in the steps before but I fully understand that this approach does not fit into your current design or architecture (or you do not have any requirements on your own that makes saving the source code path necessary). 

Thanks for your help!

Your example with packages will probably not work as due to split-packages (think of main/test) there is not a single location for a package.

Yes, that is true. For SpotBugs or Cobertura I am currently looping over a list of source file paths (in the XML file) that I need to check for the actual files. But this is simpler than totally guessing where those files are located (since in Jenkins I do not know if the build process is using ant, maven, gradle, etc.)

Reply all
Reply to author
Forward
0 new messages