In case of jacoco - we can skip packages which should not be considered for code coverage.
I want to exclude some methods from Java class, not the whole class.
Can we specify specific which can be excluded?
If yes, where and what configuration changes are required.
I don't want to add annotations on the methods which needs to be excluded. Is there any way to configure. Like if we list down all the methods in 1 file and while executing code coverage, read that file via some configuration and exclude those methods. Is this possible ?
Related
I want to generate reports for particular java code(newly added particular method).I do not want to generate report for whole project.Is it possible with Jenkins?I am using JUnit for writing test cases.
try integrating with SONAR, and define include / exclude patterns for you case
I went through the https://github.com/pmayweg/sonar-groovy
In README.md it specified few properties need to mention, but I am not able to identify where and in which file I have to mention them.
Actual information defined in pmayweg/sonar-groovy/README.md:
CodeNarc It is possible to reuse a previously generated report from CodeNarc by setting the sonar.groovy.codenarc.reportPaths property.
Groovy File Suffixes It is possible to define multiple groovy file suffixes to be recognized by setting the sonar.groovy.file.suffixes property. Note that by default, only files having .groovythe as extension will be analyzed.
Unit Tests Execution Reports Import unit tests execution reports (JUnit XML format) by setting the sonar.junit.reportsPath property. Default location is target/surefire-reports.
JaCoCo and Binaries The groovy plugin requires access to source binaries when analyzing JaCoCo reports. Consequently, property sonar.groovy.binaries has to be configured for the analysis (comma-separated paths to binary folders). For Maven and gradle projects, the property is automatically set.
Finally, I find out
sonar-scanner.properties in sonar-scanner/conf or
sonar-project.properties in your project.
So, at work, I frequently have to create virtually identical ant scripts. Basically the application we provide to our clients is designed to be easily extensible, and we offer a service of designing and creating custom modules for it. Because of the complexity of our application, with lots of cross dependencies, I tend to develop the module within our core dev environment, compile it using IntelliJ, and then run a basic ant script that does the following tasks:
1) Clean build directory
2) Create build directory and directory hierarchy based on package paths.
3) Copy class files (and source files to a separate sources directory).
4) Jar it up.
The thing is, to do this I need to go through the script line by line and change a bunch of property names, so it works for the new use case. I also save all the scripts in case I need to go back to them.
This isn't the worst thing in the world, but I'm always looking for a better way to do things. Hence my idea:
For each specific implementation I would provide an ant script (or other file) of just properties. Key-value pairs, which would have specific prefixes for each key based on what it's used for. I would then want my ant script to run the various tasks, executing each one for the key-value pairs that are appropriate.
For example, copying the class files. I would have a property with a name like "classFile.filePath". I would want the script to call the task for every property it detects that starts with "classFile...".
Honestly, from my current research so far, I'm not confident that this is possible. But... I'm super stubborn, and always looking for new creative options. So, what options do I have? Or are there none?
It's possible to dynamically generate ANT scripts, for example the following does this using an XML input file:
Use pure Ant to search if list of files exists and take action based on condition
Personally I would always try and avoid this level of complexity. Ant is not a programming language.
Looking at what you're trying to achieve it does appear you could benefit from packaging your dependencies as jars and using a Maven repository manager like Nexus or Artifactory for storage. This would simplify each sub-project build. When building projects that depend on these published libraries you can use a dependency management tool like Apache ivy to download them.
Hope that helps your question is fairly broad.
I have three projects which are stored in three separate repositories. Each of them is a individual mvn project. I wonder is there a way to aggregate three reports in one?
I took a look at the cobertura aggregate function. But seems like it can only handle sub-modules of a project.
Anybody has any suggestion?
The Maven plugin goal cobertura:cobertura supports an aggregate parameter that would work for all the projects in the reactor I suppose.
But you seem to suggest the projects might not be in the same structure/reactor, and i wouldn't know how to do it with maven per-se. However, you can easily do it with a little ant script that can be integrated in your maven structure.
The Cobertura Ant library has a merge task that can merge a number of .ser files (generated by the runtime execution of your instrumented code). This will generate a combined .ser file for which you can generate a xml or html report from.
Let me know if you need more pointers.
In another question a responder gave a link to a python script they had written that did what you are asking, I moved that "xml combiner" to a gist that is located here
Being a Maven newbie, I want to know if its possible to use multiple classifiers at once; in my case it would be for generating different jars in a single run. I use this command to build my project:
mvn -Dclassifier=bootstrap package
Logically I would think that this is possible:
mvn -Dclassifier=bootstrap,api package
I am using Maven 3.0.4
Your project seems like a candidate for refactoring into a couple of what Maven calls "modules". This involves splitting the code into separate projects within a single directory tree, where the topmost level is normally a parent or aggregator POM with <packaging>pom</packaging> and a <modules/> list containing the sub-project directory names.
Then, I'd advise putting the API interfaces/exceptions/whatnot into an api/ subdirectory with its own pom.xml, and putting the bootstrap classes into a bootstrap/ subdirectory with its own pom.xml. The top-level pom.xml would then list the modules like this:
<modules>
<module>api</module>
<module>bootstrap</module>
</module>
Once you've refactored the project, you will probably want to add a dependency from the bootstrap module to the api module, since I'm guessing the bootstrap will depend on interfaces/etc. from the api.
Now, you should be able to go into the top level of the directory structure and simply call:
mvn clean install
This approach is good because it forces you to think about how different use cases are supported in your code, and it makes dependency cycles between classes harder to miss.
If you want an example to follow, have a look at one of my github projects: Aprox.
NOTE: If you have many modules dependent on the api module, you might want to list it in the top-level pom.xml in the <dependencyManagement/> section, so you can leave off the version in submodule dependency declarations (see Introduction to the Dependency Mechanism).
UPDATE: Legacy Considerations
If you can't refactor the codebase for legacy reasons, etc. then you basically have two options:
Construct a series of pom.xml files in an empty multimodule structure, and use the build-helper-maven-plugin along with source includes/excludes to fragment the codebase and allocate the classes to different modules out of a single source tree.
Maybe use a plugin like the assembly plugin to carve up the target/classes directory (${project.build.directory}) and allocate classes to the different jars. In this scenario, each assembly descriptor requires an <id/> and by default this value becomes the classifier for that assembly jar. Under this plan, the "main" jar output will still be the monolithic one created by the Maven build. If you don't want this, you can use a separate execution of the assembly plugin, and in the configuration use <appendAssemblyId>false</appendAssemblyId>. If the output of that assembly is a jar, then it will effectively replace the old output from the jar plugin. If you decide to pursue this approach, you might want to read the assembly plugin documents to get as much exposure to different examples as you can.
Also, I should note that in both cases you would be stuck with manipulating the list of things produced by using a set of profiles in the pom in order to turn on/off different parts of the build. I'd highly recommend making the default, un-qualified build one that produces everything. This makes it more likely for things like the release plugin to catch everything you want to release, and up-rev versions, etc. appropriately.
These solutions are usually what I promote as migration steps when you can't refactor the codebase all at once. They are especially useful when migrating from something like an Ant build that produces multiple jars out of a single source tree.