Exclude classpath libs from coverage.

[pravi...@gmail.com]

I am using Jacoco with Ant for codecoverage. In my build script file, I am running 'Jacoco:coverage' with Junit on two projects.(I have 2 projects in my workspace with single build script.). 'Jacoco:coverage' task is running successfuly for 1st project but it is giving errors for second project. one of of those is as bellow-
Caused by: java.lang.IllegalStateException: Class org/junit/runner/notification/RunNotifier$SafeNotifier is already instrumented.

Build file tags (snap) are as bellows-
<jacoco:coverage destfile="${log.jacoco.dir}/${project.name}/jacoco.exec">
<junit printsummary="yes" errorProperty="test.failed" failureProperty="test.failed" haltonfailure="yes" fork="true">
..
...
..
</junit>
<jacoco:coverage>

also, classpath variable is being shared between two projects (above jacoco:coverage task is being called in loop).

So from my understanding, due to all classes from classpath variable are already been instrumented in first iteration, it is giving 'class is already instrumented' error in next iteration.

Is there any way where we can exclude third party jars from instrumentation. I tried with excludes option of <jacoco:coverage> tag where we can exclude classes, but in my case I have multiple jars in classpath so its not feasible to mentioned every class names (even regex with package)

[Mirko Friedenhagen]

Hello Anonymous,

long time since I did something with Ant :-). Do you fork the JVM for testing? Then the agent should get a fresh chance to instrument classes. If building and testing of both projects run on the same JVM I would expect such errors.

Regards
Mirko
--
Sent from my mobile

--
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/cb0cb143-4c50-4f6c-8bad-bb136f8f4899%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Marc R. Hoffmann]

Ok, I see two issues here:

1) "already instrumened"

By any chance do you use the jacoco:instrument task in your build?
jacoco:coverage does pure in-memory instrumentation and will not persist
any instrumented classes on disk.

2) Exclude 3rd party Jars

Instead of excluding 3rd party Jars I would recomment to limit the scope
to your code onlye with includes=com.mycompany.*

Regards,
-marc

[pravi...@gmail.com]

Thanks Mirko for your updates.
I am using fork option while running Junit task (fork="true")
e.g.

<junit printsummary="yes" errorProperty="test.failed" failureProperty="test.failed" haltonfailure="yes" fork="true">

But still there is problem :(

Regards
-Pravin

[pravi...@gmail.com]

Thanks Marc,
1) "already instrumened" -

I am using "on-the-fly instrumentation" with <jacoco:coverage> tag. so you might be right that already instrumented class might be residing in memory and with second iteration of <jacoco:coverage> getting "already instrumented" error. I can you use offline instrumentation with < jacoco:instrument> but is there any performance issue associated with offline issue ? What is recommended way for instrumentation (offline or on the fly) ? Is there any extra care needs to be taken for offline instrumentation, so that instrumented classes should not be part of jar or war.

2) Exclude 3rd party Jars

Scope limit with class name is not feasible for me as there are lot many jars in classpath. I can limit those classes while generating jacoco report

Thanks,
-Pravin

[Marc R. Hoffmann]

Hi Pravin

on-the-fly instrumentation is the recommended way as it simplifies test
setups a lot. Every class is instrumented only once when loeaded into
the JVM. Another possible cause is when two JaCoCo agents from different
JaCoCo releases are applied to the same JVM. JaCoCo documentation
includes a working Ant example:

http://www.eclemma.org/jacoco/trunk/doc/examples/build/build.xml

If you run your build with -debug and provide the output log I might
have a chance to see what's going wrong with your build.

Re scope: Normally there is no reason to exclude any classes during test
execution. You simply specify the scope when you generate the report.

Regards,
-marc

[luvr...@gmail.com]

Hi Mark,

Need some help on this. I want to it using the ReportGenerator.java provided in the examples. I am not getting how to restrict the reports to specific classes?
Is it a vice idea to collect all required .java files in one folder say mysource and then give it as a sourceDirectory? Do I need to maintain the structure like com/jacoco/examples... etc?

Thanks for help!

[Marc R. Hoffmann]

Hi,

yes, the source files must be in the propert directory structure reflecting their Java packages, see FAQ below.

Regards,
-marc


http://www.eclemma.org/jacoco/trunk/doc/faq.html

Why does the coverage report not show highlighted source code?

Make sure the following prerequisites are fulfilled to get source code highlighting in JaCoCo coverage reports:

• Class files must be compiled with debug information to contain line numbers.
• Source files must be properly supplied at report generation time. I.e. specified source folders must be the direct parent of the folders that define the Java packages.