Source path is not stored in report XML

[Ullrich Hafner]

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]

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]

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.  

To view this discussion on the web visit https://groups.google.com/d/msgid/jacoco/97A31987-51E5-43BB-8849-8ADF1D2D6CC5%40mountainminds.com.

[Marc Hoffmann]

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

To view this discussion on the web visit https://groups.google.com/d/msgid/jacoco/7B93A391-E901-4949-8A45-B725B44C446A%40gmail.com.

[Ullrich Hafner]

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.)

To view this discussion on the web visit https://groups.google.com/d/msgid/jacoco/33810F30-711A-4CEC-B21B-C100A66CD896%40mountainminds.com.