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. For more options, visit https://groups.google.com/d/optout.
