I am looking for a way to exclude specific class methods in my jacoco analysis. I am aware of the "excludes" property but that only applies to entire classes.
In my case i have generated methods that distort the coverage report so i would like to exclude them from the report.
JaCoCo supports now (in 2018, I know the question is from 2012) since version 0.8.0 (released on 2018/01/02) ignoring methods with annotion #lombok.Generated.
So this can be used as a workaround also for other generated methods (if you are able to tag them this way) or even for "hand-written" methods if you really want (although this was probably not the intention of the authors).
You can actually use wildcards in the excludes property, that is if you're using ant to run the jacoco unit test:
Blockquote
excludes - A list of class names that should be excluded from execution analysis. The list entries are separated by a colon (:) and may use wildcard characters (* and ?). Except for performance optimization or technical corner cases this option is normally not required.
http://www.eclemma.org/jacoco/trunk/doc/ant.html
You can also exclude files from the report generation process using simple ant fileset tasks:
<jacoco:report>
<executiondata>
<file file="jacoco.exec"/>
</executiondata>
<structure name="Example Project">
<classfiles>
<fileset dir="classes"/>
</classfiles>
<sourcefiles encoding="UTF-8">
<fileset dir="src"/>
</sourcefiles>
</structure>
<html destdir="report"/>
</jacoco:report>
You may have to experiment with the two to get the desired results.
Related
I have two situations I need a checkstyle check for. Let's say I have a bunch of objects with the annotation #BusinessLogic. I want to do a first pass through all *.java files creating a Set with the full classnames of these objects. Let's say ONE of the classes here is MyBusinessLogic. NEXT, and as part of a custom checkstyle checker, I want to go through and fail the build if there is any lines of code that say "new MyBusinessLogic()" in any of the code. We want to force DI when objects are annotated with #BusinessLogic. Is this possible with checkstyle? I am not sure checkstyle does a dual pass.
Another option I am considering is some gradle plugin perhaps that scans all java files and writes to a file the list of classes annotated with #BusinessLogic and then running checkstyle after that where my checker reads in the file?
My next situation is I have a library delivered as a jar so in that jar, I also have classes annotated with #BusinessLogic and I need to make sure those are also added to my list of classes that should not be newed up manually and only created with dependency injection.
Follow up question from the previous question here after reading through checkstyle docs:
How to enforce this pattern via gradle plugins?
thanks,
Dean
Is it possible to write a dual pass checkstyle check?
Possible, yes, but not officially supported. Support would come at https://github.com/checkstyle/checkstyle/issues/3540 but it hasn't been agreed on.
Multi-file validation is possible with FileSets (still not officially supported), but it becomes harder with TreeWalker checks. This is because TreeWalker doesn't chain finishProcessing to the checks. You can implement your own TreeWalker that will chain this finishProcessing to implementation of AbstractChecks.
You will have to do everything in 1 pass with this method. Log all new XXX and classes with annotation #YYY. In the finishProcessing method, correlate the information obtained between the 2 and print a violation when you have a match.
I have a library delivered as a jar
Checkstyle does not support reading JARs or bytecode. You can always create a hard coded list as an alternative. The only other way is build your own reader into Checkstyle.
When creating a new "Config" we define a function that takes three "View"s (site, here, up) as arguments. What is the meaning of these three Views?
As purely a historical reference, take a look at the Chisel2 Advanced Parameterization Manual (with the huge caveat to not take this too literally as it's old). However, I believe that the motivation and discussion of site, here, and up still holds in sections 2.6, 2.7, 2.8, and 3.6.
Roughly, site, here, and up help with handling and resolving dependencies on other parameters.
site allows you to disambiguate different parameters that may have the same name, e.g., Width, based on a defined location. here allows parameters to query other parameters defined in the same group. up allows you to access a parent configuration's parameter object with the intended purpose being if you want to copy it while modifying parameters.
class Blah extends Config ((site, here, up)) {..}
is the parameter tuple, which allows partial function application. This allows partial configuration of the Rocket core and setting default parameters, preserving elasticity and type correctness.
You may check its implementation here
I using Jacoco as code-coverage plugin configured inside my pom.xml. I want to test and analyse coverage of only a few methods from my class file and want to show coverage percentage accordingly for them only. But as jacoco analyse whole file it shows less coverage, though the methods concerned are covered 100%.
Is there any way out in jacoco to exclude some methods being analysed without changing source file code?
That's not possible. Jacoco allows inclusions and exclusions at class level but not at method level.
There is some support for filtering at method level, discussed here. This allows Jacoco to ignore extraneous byte code generated by the Java compiler. On a similar note; Jacoco can also ignore some generated code on the basis of annotations (such as code generated by Lombok)
Although there is currently no way to tell Jacoco (via the Maven plugin, for example) to ignore specific methods, there are some open Jacoco issues related to this:
Filtering options for coverage analysis
Investigate filtering with annotations
You could perhaps vote for those and/or raise another issues for your specific requirements.
It is not clear why you "want to test and analyse coverage of only a few methods from my class file and want to show coverage percentage accordingly for them only."
May be you have some code which is not related to main class? In this case think about design. One of possible solution is to split your class to parent and child or main class and some utilities.
May be 2 developers are working with the same class you each wants to show only own results?
May be some code hard to test? Try the mocking way.
I log my explorations of RDF data by executing SPARQL queries in a Jupyter notebook (Web-based REPL environment).
Very often I create a query by copying the previous query for tweaking. The notebook fills up with SPARQL queries that all start with the same eight PREFIX definitions (e.g., PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>).
I keep the PREFIX list short in order to reduce clutter, but this means I must often switch windows to search some other prefix that must be added (e.g., PREFIX eurovoc: ...).
Is there a way to save PREFIX definitions in a file, then simply import those definitions into a query?
Alternatively, since I currently execute the queries in Jupyter Notebook using the Apache JENA command-line utility arq, I'd be happy for any command-line utility that allows a SPARQL query to be split into multiple files, or other such workarounds.
I searched for an answer to the question on stackoverflow.com and on the Web by trying many queries involving the words SPARQL, PREFIX, declaration, definition, reundant, import, re-use, reuse, namespace, binding, separate, file, and multiple, which I reproduce here in order to make this question more easily findable by others who may be asking the same question.
I've just stumbled upon this question, while looking for something similar. AFAIK, SPARQL has no import directive, but there are tools like rdf.sh, which can look at all the prefixes you use in a file and build the required definitions (they're usually based on prefix.cc).
Moreover, I've seen endpoints (eg, Fuseki) that have predefined prefix definitions and complete your SPARQL automatically, but relying on them makes queries less portable.
Is there a way to use the maven-processor-plugin (or any other plug-in) to execute annotation processors listing the ones to skip? I have little control on the processors my dependencies might use but I do know the one I want skipped.
The only option in the usage page is to list the ones you want to include but not the other way around.
Is there a way to do this in Maven?
This is not a question of the maven plugin, but of the availability of javac options. According to the javac reference on annotation processing
Processors are located by means of service provider-configuration files named META-INF/services/javax.annotation.processing.Processor on the search path. Such files should contain the names of any annotation processors to be used, listed one per line. Alternatively, processors can be specified explicitly, using the -processor option.
So for now there's no way to remove an annotation processor, just whitelist the ones you want to run.