I need to write a Sonar plugin to keep track of the library classes that are used the most in a project.
So far I read the Coding a Plugin guide but I am a little bit confused. Does Sonar provide any facility to perform analysis (Something like parsing of Java code, creation of Abstract Syntax Trees, ...) or should I look for an external tool that does it and use Sonar only as a reporting tool?
Sonar provides a framework for publishing your own code analysis results into to Sonar so that they are in a single place. Although it does some analysis of it's own it mostly relies on other static code analysis tools and just integrates them into the lifecycle, e.g., test coverage can be implemented by cobertura or clover.
Sounds to me though like you just to get a measure of the Afferent couplings which can be configured for a single library. Not sure how you would manage it for cross library dependencies as most of the plugins work by using instrumenting the code at compile time which would not be possible for classes already in a jar.
If you just want to generate an AST then you should check out this question.
Related
We have some old Maven1 project (we cannot upgrade it to the latest maven versions) so I am just trying to understand if there is a way we can run SonarQube on Maven1 version projects..?
If not what is the best alternate to analyze the code quality other than SonarQube?
Modern Maven projects are easy to analyze using the specialized scanner for Maven: it discovers the necessary configuration from Maven's metadata, most notably, the sources, test sources, compiled Java bytecode, and additional information that can improve the quality of the analysis, such as library dependencies.
Without such specialized tool that makes the configuration easy, you can always fall back to the most primitive scanner tool, the SonarQube Scanner CLI.
Using this tool, you can certainly analyze a Maven1 project, you just have to configure it correctly. This may not be very convenient, but certainly doable. Start with something simple, follow the error messages to get it working, then follow the warnings to get it working well.
I am using Spotbugs plugin within Eclipse IDE. I can run the Spotbugs over a whole project, which gives me the impression that the tool needs to build the project to present its analysis report.
But the documentation says that it's a static analysis tool.
So, I was curious if it requires to build the project, then can we call it a Static Analysis Tool?
And if it doesn't require to build the project, can we run Spotbugs on single .java files?
The meaning of static analysis is that it analyses your project files "at rest", as opposed to monitoring a running application. https://en.wikipedia.org/wiki/Static_program_analysis
Analyzing bytecode has both strengths and weaknesses compared to analysing source code. It's faster, and better suited to deep analysis of program flow, but won't pick up mistakes that get compiled away, like unnecessary imports and inconsistent-but-legal whitespace.
You can't properly run it on a single file, even if you compiled that file, because there are detectors that take multiple files into consideration, eg detecting when you try to pass null to a method whose parameters are annotated as non-null, or when you've defined a method as public and then never called it from outside the class.
Yes, since SpotBugs analyzes bytecode (.class files), you must first build the project (at least the part you want to analyze).
After that, you can analyze just a single file, for example in IntelliJ IDEA (still FindBugs plugin, but SpotBugs can do all that FindBugs could, same code base):
Can a custom Maven plugin use incremental build support from core Maven or would it best have to implement that completely itself, with SHA1 hashes over the input and the like?
Noticed e.g. /target/maven-status/maven-compiler-plugin/compile/default-compile with createdFiles.lst and inputFiles.lst, so thinking that an existing custom e.g. code generator Maven plugin, which reads some files as input, generates some output, may be able to be changed to correctly use Maven Plugin APIs for incremental build? Unclear what specifically that plugin code would have to do differently than it does today for it to become incremental. Doesn't look like there is any doc about this?
Existing code does use e.g. org.sonatype.plexus.build.incremental.BuildContext.hasDelta(File), but with "return true" in org.sonatype.plexus.build.incremental.DefaultBuildContext.hasDelta(File) it's not surprising that this doesn't quite work... ;-) Is this not implemented in Maven, or can be configured differently? Would this require the takari-lifecycle-plugin? (That would be a problem in the case of the particular plugin I'm asking for, because the use of takari-jar instead of normal JAR would interfere with other plugins.)
Understood that the custom Maven plugin likely would have to interface with Maven core API to expose its notion of dependencies between the input files. In the case of this particular custom Maven plugin, some of the input is read from dependencies on the project's classpath. Would the incremental support be able to handle that as well?
Understood that existing Maven plugins, such as maven-compiler-plugin, are struggling with incremental builds (à la Gradle); see [1], [2] and [3], so this Q is specifically to learn about how a custom Maven plugin may be extended to support incremental build.
[1] http://takari.io/2014/10/16/incremental-compilation.html
[2] http://takari.io/book/40-lifecycle.html
[3] Does Maven support incremental builds?
can Maven custom plugins use incremental build support from core Maven?
yes. take a look on the sources of 'querydsl-maven-plugin'. also you can find more usages of BuildContext.hasDelta method with grepcode.com.
does it have to implement that itself?
may it? yes. have to? no.
usually such question means just an unnecessary preemptive optimization. you have to have a rational reason to look forward on incremental builds, before you start implement anything.
I am have successfully setup Sonar to do some analysis on my C# project where we are already making use of NCover. Our code has NCover exclude attributes and we would like to use these in Sonar to make the analysis meaningful. I have managed to find a few things on the web (e.g. http://marc.info/?l=sonar-user&m=133896735312253) but the links to the JIRA is dead and doensnt ever seem to have been addressed. Does anyone know if it is possible to make use of NCover exclude attributes within Sonar? If not then we will have to look at alternatives.
The SonarQube C# plugin (since version 3.x) only imports code coverage reports generated by 3rd party tools. The information on which lines are to be covered by tests (i.e. "executable" lines), as well as which lines actually were covered by tests, are provided by the report generated by the tool.
These NCover exclusions should be applied by NCover itself, and should not require special support from SonarQube.
We have Desktop app deployed in OSGI bundles and have integration tests to test bundles loaded in OSGI container.
I am seeking a tool that calculates code coverage for integration tests with OSGI bundles
Currently we are trying to do with Jacoco and Sonar that is good for integration tests code coverage, but we aren't sure whether they are good enough to handle OSGI integration test code coverage
also any other tools available to calculate OSGI integration test code coverage.
Most, if not all code coverage tools should work with OSGi. Their general strategy is to post process the bytecode to inject extra code that allows them to measure such coverage. The biggest issue that causes is that this code now usually has dependencies on extra code (the code coverage library). Such dependencies can either be made explicit (by adding Import-Package statements) just like with any other dependency.
The other option you have is to add the code coverage library to your bootclasspath so you don't need those extra imports (which breaks modularity, normally not something you want, but in this case irrelevant). Once you solve this problem, the rest is a matter of instrumenting the right bundles and aggregating the results of multiple different test runs.
We proceeded in second approach and it worked..Jacoco is able to provide Test Coverage of OSGI integration test and show in Sonar DashBoard.