Ability to specify excludes via file #102
Conversation
| @@ -158,6 +159,11 @@ private boolean checkCounter(final CounterEntity entity, | |||
| String.format(INSUFFICIENT_COVERAGE, entity.name(), | |||
| truncate(ratio), truncate(checkRatio))); | |||
| passed = false; | |||
| } else { | |||
| if (!Double.isNaN(ratio) && !Double.isInfinite(ratio)) { | |||
There was a problem hiding this comment.
I have feeling that this piece of code does not relate to the subject of the pull-requestion ("ability to specify excludes via file") and this is completely separate issue.
There was a problem hiding this comment.
Yes, I just added this so I can see what the coverage is when it passes (as of now it only prints the coverage if it fails). If you feel it shouldn't be here, I can remove this.
|
re: marchof Does anyone still use Ant? Ok just kidding :) I suppose the same could be done for Ant, but I haven't looked at it. From what I've seen with other tools, maven plugins generally have more features, since more people use them and they're kept up to date. To answer your second point, this is using the same mechanism as the existing "excludes" parameter. It's just a different way to specify the excludes (I wouldn't want to specify 100 excludes in a pom). If the excludes mechanism is made to work with class names, then this would work with classnames automatically. I think this is related to issue #15 but it's an addition to that. I don't think this specific feature is discussed in that issue. |
|
BTW, unfortunately we already have an inconsistency in the existing includes/excludes parameter, see #34. What is the reasoning behind having an excludes file but no includes file? Shouldn't the API stay symmetrical? |
|
I created just excludes mechanism because that's what I needed to solve my problem. But I can definitely add the same for includes. Let me know if you want me to do that, I can work on it when I have some free time. |
|
Andrey, I'd want that. Though with YAGNI and TDD I see why you've added only excludes. After all, it's seems more likely, right? So, use case for includes: I want JaCoCo to measure only my code, since I know my colleagues won't write tests anyway (say, for legit reasons). Or I'm writing code that touches legacy and I want to know my own coverage only - thus list of includes is better. Marchof, somewhat related question. I found nice link on the Wiki - I have a set of generated methods (yeah, METHODS, not classes) that I'd like exclude from coverage - have I missed something in the config options that allows me to do that or that ain't an option ATM with JaCoCo? If it cannot be done at present, how likely do you see it? (feel free to point me to mailing list if you so prefer, I'll comply) |
|
@LIttleAncientForestKami No, JaCoCo does currently not support filtering on method level. That's why I was asking whether the filtering feature should really be based on input files for the Maven goal only. An alternative would be to filter on class/method names provided by the core APIs. |
|
@marchof filtering by API is IN the code, so no issues with "how was I supposed to know that we have a file that filters out..." etc. I too think it's better. Especially since it's tool-agnostic. Ant or Maven or Gradle, as long as it's your API rest matters not. How hard would it be to add such annotation - with appropriate processing? |
|
It would be pretty nice to see this for the agentlib as well. Constructing command line parameters is error prone due to shell escaping etc. |
|
Should be considered in the context of the filtering story. No singular solution for Maven only. |
I'd like to add the ability to specify jacoco excludes via a file. Currently, it seems only 2 mechanisms exist for excluding code from coverage metrics:
Neither of these really work well to solve the problem we have. We have a large legacy codebase, where unit test standards were not observed. We want to introduce a check in the build for some % of code coverage. In order to do this, we have to exclude hundreds of files from the metrics. We don't want to put that into the pom, and we don't want to modify all these files with annotations.
The solution we came up with basically uses the same mechanism as the existing "excludes" plugin parameter, it just loads the list of files from a file.