> Am 25.11.2021 um 09:49 schrieb Marc Hoffmann :
>
> 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 repo
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 pac
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 analysi
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 wrote:
>
> I'm currently trying to improve th
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
quali
