[Jacoco] Multi module Maven itests transitive coverage

[cmor...@gmail.com]

Hi,

I read about issue #195 and #97 but both of these haven't been merged in the master (closed and pull not accepted).

So I deduced that it is always not possible to have Itests covered lines for submodules?

For example, let's have a project made with two modules, my.biz and my.data: my.biz having my.data as dependency.

It's allgood for me that test coverage on my.biz covers only classes from the my.biz module, but for INTEGRATION tests, coverage on my.biz should covers classes from my.biz AND my.data (all solutions I tried from now ended with only my.biz covered classes report).

Is it possible to do this? How? Have you got a pointer?

Thank you in advance.

Regards,

[Marc R. Hoffmann]

Hi,

we have to separate two things:

1) Execution data sampling during test execution: The JaCoCo agent
samples execution data for all classes loaded into the JVM, therefore
also classes from the dependencies.
2) Coverage report generation: Our Maven report goal only considers the
classes from a single module -- here is the actual limitation for multi
module tests.

Especially PR #195 tries to address issue 1) which is actually not the
point.

Currently there are at least two workarounds:

1) Create the report with the report Ant task. The JaCoCo build itself
does it this way.
2) Use SonarQube for reporting which can deal with multiple reports.

Best regards,
-marc

[rop...@gmail.com]

Hi Marc,

I am also struggling with this issue of code-coverage across multiple maven subprojects.
Seems like you have a thorough understanding of this frustrating stuff :)

In the top answer to this thread:
stackoverflow.com/questions/13031219/how-to-configure-multi-module-maven-sonar-jacoco-to-give-merged-coverage-rep
mpontes shows a solution.

I tried it on my own project, but sonarQube actually reports LOWER overall code-coverage
than with normal module-by-module unit-test coverage,
so I guess it's not entirely correct?

Can you confirm that it is an incorrect solution?

Still, I wonder if it would be possible to fix it...
is it a possible solution, "to apply the integration tests logic to regular unit tests"
as he puts it?

BR,

[rop...@gmail.com]

UPDATE:
I just discovered, the reason I got LOWER percentage from mpontes' suggested solution, was due to an error of mine in the way I applied it.
When I corrected the pom's, indeed I got HIGHER coverage-percent as expected.

So now it seems to me, his solution actually works -- nice trick :)

http://stackoverflow.com/questions/13031219/how-to-configure-multi-module-maven-sonar-jacoco-to-give-merged-coverage-rep

On Sunday, June 8, 2014 3:34:22 AM UTC+2, rop...@gmail.com wrote:
> Hi Marc,
>
> I am also struggling with this issue of code-coverage across multiple maven subprojects.
> Seems like you have a thorough understanding of this frustrating stuff :)
>
> In the top answer to this thread:
> stackoverflow.com/questions/13031219/how-to-configure-multi-module-maven-sonar-jacoco-to-give-merged-coverage-rep
> mpontes shows a solution.
>
> I tried it on my own project, but sonarQube actually reports LOWER overall code-coverage
> than with normal module-by-module unit-test coverage,
> so I guess it's not entirely correct?
>
> Can you confirm that it is an incorrect solution?
>
> Still, I wonder if it would be possible to fix it...
> is it a possible solution, "to apply the integration tests logic to regular unit tests"
> as he puts it?
>
> BR,
>
>
> On Monday, May 19, 2014 10:04:51 PM UTC+2, Marc R. Hoffmann wrote:

[Marc R. Hoffmann]

Glad you figured it out! What actually was the problem with your
configuration? Maybe others can avoid making the same error.

Best regards,
-marc

[Charlie Mordant]

I too have a lower coverage in sonar and I'm really interested by the answer.

Can you give it? either on SOF or here?

Thanks in advance.

Regards,

--
You received this message because you are subscribed to a topic in the Google Groups "JaCoCo and EclEmma Users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/jacoco/-VCbA69Rlhs/unsubscribe.
To unsubscribe from this group and all its topics, send an email to jacoco+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Charlie Mordant

Full OSGI/EE stack made with Karaf: https://github.com/OsgiliathEnterprise/net.osgiliath.parent

[rop...@gmail.com]

Hi Charlie,

In my case, it was a bit irregular pom-structure, so not all submodules inherited from the parent-pom. When fixing that, it worked.

Just looking at the code in the stackoverflow link, it also seems like it assumes all submodules are one only level down from the parent-pom.
I'm just guessing here, but if your project structure goes deeper than that, I suspect the reportPath needs to contain ../.. rather than just .. for the second level pom's, ../../.. for third level, etc...

> To unsubscribe from this group and all its topics, send an email to jacoco+un...@googlegroups.com.