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, 2014-06-10 6:27 GMT+02:00 Marc R. Hoffmann <[email protected]>: > Glad you figured it out! What actually was the problem with your > configuration? Maybe others can avoid making the same error. > > Best regards, > -marc > > > On 10.06.14 01:13, [email protected] wrote: > >> 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, [email protected] 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: >>> >>>> 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 >>>> >>> > -- > 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 > [email protected]. > 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 -- 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
