JaCoCo - sample API code to copy an exec file?

[John A]

Is there some sample code that uses the JaCoCo API to copy an exec from one file to another?

I'd like to use this as a starting to create a filtering mechanism.

      java -jar mycool.jar strip oldfile.ec newfile.ec  'android.*' 'com.facebook.*'   'com.some.package.name'

Here's some pseudo code:

• create an empty output file
• read exec file, package by package
• if a particular package is in an exclude list, skip
• otherwise write the package to the output file

At the end of it, the new output file will be usable to generate a report using the normal existing command line.

I'm starting to look through the API Usage Examples https://www.jacoco.org/jacoco/trunk/doc/api.html but so far nothing jumps out...

Some sample code will make the ramp up time much quicker.

TIA!

John

[Evgeny Mandrikov]

https://www.jacoco.org/jacoco/trunk/doc/examples/java/ExecDump.java

shows how to read execution data

JavaDoc of API - https://www.jacoco.org/jacoco/trunk/doc/api/org/jacoco/core/data/package-summary.html

[John A]

Yes I saw that too.

And the Merge command has the ability to copy from one exec to another. It would be ideal to add a new arg --exclude to this command that takes a regex or glob and excludes any matching package names. That way as the final merged .exec file is being created, it simply strips out those packages from *all* the incoming exec files and so the final outgoing file is clean. Note if you only name one incoming exec file then this is equivalent to the "strip" command, i.e. I get two for one.

John 

[Evgeny Mandrikov]

On Monday, November 5, 2018 at 4:35:00 PM UTC+1, John A wrote:

Yes I saw that too.

 

And the Merge command has the ability to copy from one exec to another.

Sorry, but then what is exactly not clear about API for you?

 

It would be ideal to add a new arg --exclude to this command that takes a regex or glob and excludes any matching package names. That way as the final merged .exec file is being created, it simply strips out those packages from *all* the incoming exec files and so the final outgoing file is clean.

If you are trying to interest others by this, then IMO you should elaborate(explain) more about why(when) this is(can be) useful for others?

Are you trying to exclude classes from report? Note that zeros will be shown in a report that is generated for classes not presented in execution data - this is equivalent to the case when class was not executed at all.

 

Note if you only name one incoming exec file then this is equivalent to the "strip" command, i.e. I get two for one.

In addition to unclear goal, mix of "strip" on two, "merge" and "exclude" IMO look misleading and error-prone in use.

In any case I believe that you can do all of these operations using API after careful reading of javadocs and examples.

Regards,

Evgeny

[John A]

On Monday, November 5, 2018 at 4:45:51 PM UTC-8, Evgeny Mandrikov wrote:

Sorry, but then what is exactly not clear about API for you?

The API is clear. My concern is that there are two visitors needed: sessioninfos and one for executiondata. If I exclude from executiondata do I need to exclude from sessioninfo as well? I'm assuming so but I haven't tried it yet. 

It's clear that I need to replacing the visitor(s) with one that allows a filter/strip/exclude based on package name and list of exclusion patterns. The details for this... still working on it :)

 

It would be ideal to add a new arg --exclude to this command that takes a regex or glob and excludes any matching package names. That way as the final merged .exec file is being created, it simply strips out those packages from *all* the incoming exec files and so the final outgoing file is clean.

If you are trying to interest others by this, then IMO you should elaborate(explain) more about why(when) this is(can be) useful for others?

Yes, it would be great if this was already in place and even better if someone else wrote it and it was perfect :) 

To me, the use case is clear since the plugins gradle, maven and ant have the ability to exclude. I may have misunderstood the intention behind exclusion in those plugins?

But let me be explicit. I want the ability to exclude system level and 3rd party packages. In my case we have an android app and the Jacoco report shows packages like:

• rx.android
• android.support.coreui
• android.support.test.runner
• android.many.others
• 3rd party libraries we use in our app
• etc.

This is causing concern to other folks since they are looking for a simple percentage coverage number to report to senior management, e.g. "our E2E tests cover 80% of the code base". Since these other packages are showing up in the report I need to exclude them.

That's one use case. The second is that we have several sets of tests and we want to show overall coverage of our tests across all jobs. So I'm working on the merge now and it looks good. But again there will be non-app packages in the merged report and they need to be excluded.

My constraints are:

• I don't have the permissions to change the current app build. 
• I can't use the gradle plugin. (And I haven't even confirmed that the gradle exclusion mechanism could prevent the system packages from showing up)

In short, I have to use the Jacoco CLI tools. They look comprehensive except for the ability to exclude.

 

Are you trying to exclude classes from report? Note that zeros will be shown in a report that is generated for classes not presented in execution data - this is equivalent to the case when class was not executed at all.

Some of the external packages are reporting 0%, some are not.

For example, the android.support.v7.recyclerview is reporting 65% coverage while rx.android is showing 0%

 

 

Note if you only name one incoming exec file then this is equivalent to the "strip" command, i.e. I get two for one.

In addition to unclear goal, mix of "strip" on two, "merge" and "exclude" IMO look misleading and error-prone in use.

Sorry, my bad. "strip" and "exclude" are equivalent to me. 

I thought that excluding packages during the merge would be ideal. As an incoming .exec file is being read in, then the Visitor could simply ignore any packages in the incoming file. When it writes to the output file, the excluded packages are simply not there and so don't show up in the final merged .exec file.

Overall then, if the merge command:

• did not name an exclude argument then it works as it does today. 
• had an exclude argument with one input file, then the resulting output file would be equivalent to the input file except for the excluded packages (what I called "strip")
• had an exclude argument and many input files, then the resulting output file would be merged (as it does today) except for the excluded packages

In any case I believe that you can do all of these operations using API after careful reading of javadocs and examples.

Yup, you're right. I'm just trying to simplify my effort.

[Marc Hoffmann]

Hi John,

I don't think filtering the exec file will give you the expected result: If you remove probes for certain classes from exec files these classes will still show with 0% coverage in the coverage report.

The scope of the coverage report is not determined by the classes in the exec file, but by set of classes provided to the report task. So simply exclude unwanted classes during report generation.

Regards,
-marc

--
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/50864b4a-f5f2-418a-8c00-f6a288587a3e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.