JaCoCo XML: Breaking the Logjam

Like many users. I am impacted by the issues described in Jacoco XML format cannot work as good as the binary format for multi-module maven. This topic has been closed even though the problem has not been resolved.

The topic did receive good involvment from Sonarsourcers and this led to:

We will discuss about this with the JaCoCo team:

with a link to JaCoCo issue 974 and the offer of a PR submission to allow JaCoCo do what we need it to do.

This got nowhere. The response was:

I think this has nothing to do with this issue.

I would like to suggest that someone at Sonarsource create a new JaCoCo issue (one in which no-one can make the same argument quoted above), and go ahead and submit the (previously offered) PR as a resolution to this new issue. As per the topic title, please let’s break the logjam.

2 Likes

Any thoughts? Just under a month has passed since I created this topic. Another month with zero coverage metrics in our hundreds upon hundreds of java projects (which is itself the reason why a work-around that involves adding new modules to projects is a non-starter).

Hello,

I think nobody jumped in the discussion because, to my knowledge, there is nothing new on this topic, the two existing solutions are still:

  • Split the command in two to support this coverage merge. See the posts from here.
  • Add a new module to the project, as advised by JaCoCo.

From a SonarSource perspective, you have to understand that we are not the maintainers of JaCoCo, we are only the messenger, importing what is provided to us. That being said, it’s true that the behavior you are looking for was possible thanks to a combination of JaCoCo and SonarSource tools. However, this was only possible thanks to .exec file, relying on it was not a good design since this is an internal representation, that external tools should not rely on. This was therefore never an explicitly intended feature.

We investigated the problem, and jump into the discussion to express our situation, and better understand the problem. This does not mean that we are requesting it or convinced by the feature though, we doubt merging coverage between modules is a good practice. I’m not sure making pressure on our side for a feature we are not convinced of would make sense.

At this point, we are well aware of your request, we will track it internally and make sure to take it into consideration regardless of our own opinion, but the final word to support this feature or not belongs to JaCoCo, and I can already say that there is nothing planned on the SonarSource side in the short future.

I hoe this clarifies the situation.