Marc R. Hoffmann

We have many more scenarios for filtering, explicit tagging is just one of them, please see https://github.com/jacoco/jacoco/wiki/FilteringOptions

Actually none of them are implemented. This is just a collection of requirements and possible solutions. What we need is a pluggable filtering API with default implementations for the common...

In general I don't like the idea to blur the source code to "improve" code coverage results. But annotations (of retention CLASS) or source comments might still be acceptable in...

@mchr3k What you get from source annotations are basically line numbers. If the code is compiled with debug information (which is a prerequisite for line coverage anyways) this can be...

Correct, these are the supported element types for annotations: http://docs.oracle.com/javase/7/docs/api/java/lang/annotation/ElementType.html On the other hand, if you really have "untestable" code it might be worth to refactor this code into a...

@mchr3k No, this would simply be another filter that needs to have source look-up paths configured.

@mchr3k If you fork on GitHub I'll try to keep an eye on your ideas. Note that I'm thinking towards a pluggable filtering API that should potentially cover most of...

Just one remark: If we accept that with code coverage annotations production code gets dependencies at least on the annotation library to annotate e.g. methods like ``` @jacocoOff void untestable()...

Also some of the (IT) tests allocate ports. Probably this will result in random failure with parallel builds. Out of curiosity: What are you working on to require parallel JaCoCo...

@Godin I'm not sure whether this more like a tool than a educational example about our API usage. Have you considered adding this to the CLI instead?