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
On 2018-11-06 16:40, John A wrote:
> 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.
--
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].
To view this discussion on the web visit
https://groups.google.com/d/msgid/jacoco/50864b4a-f5f2-418a-8c00-f6a288587a3e%40googlegroups.com
[1].
For more options, visit https://groups.google.com/d/optout.
Links:
------
[1]
https://groups.google.com/d/msgid/jacoco/50864b4a-f5f2-418a-8c00-f6a288587a3e%40googlegroups.com?utm_medium=email&utm_source=footer
--
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].
To view this discussion on the web visit
https://groups.google.com/d/msgid/jacoco/8f6311855d4576d2d9066810aada7522%40mountainminds.com.
For more options, visit https://groups.google.com/d/optout.
