We have a Java project, which gets built by a Jenkins job and is then analyzed by Sonar.
We used to have a view within the Sonar part of the Jenkins build results called "Clouds", which showed the complexity of a class versus its test coverage, which was a very useful metric. (See here for an example)
But now - I assume after some updates which were made to Sonar/Jenkins - it is not longer available. Can someone tell me how to get it back?
[We use SonarQube 4.5.4]
This feature is now a dedicated widget called "Project File Word Cloud" that you can add on one of your dashboards in SonarQube.
Related
How can I run code analysis the same as Android Studio performs on commit?
I tried to use Analyze - Inspect Code feature - but it shows completely different warnings that I see during code analysis on commit.
Of course, I tried Build - Make Project - it also shows different warnings and even different errors.
So, it looks like Android Studio has 3 different sets of warnings & errors. And I can't find how I can run the third of them without attempt to commit changes.
think that this "Code Analysis" is the default Android Studio inspection (Analyze > Inspect Code), as explained here - different results might be the result of using different profiles. while you can also use FindBugs (also used in some Google libraries) or add JaCoCo plugin to Gradle projects, which is Java Code Coverage for test builds.
Based of the fact that every other day Analyze - Inspect Code shows different warnings in the same code, I can suggest that Lint is malfunctioning and doesn't show all warnings. But on the pre-commit check it shows all warnings for changed files.
I am setting up sonarqube code analysis for my existing projects. I want to focus only one issues on new code and ignore already existing issues.Is there a way to export existing defects list and use it as baseline of defects which should be ignored.
I can create the project and mark all issues as Cannot be fixed/ignored. But i have to do it for every release version. We have different release versions
Thanks in Advance
If I understood well, it seems you need to flag some of your Sonar issues, so you can exclude them from results when a new analysis is performed.
You can do it by creating an Action Plan (Important: this feature has been removed from Sonar > 5.3) and assigning the issues to this Action Plan (call it "baseline").
Then, from the Issues view, you can filter by project and Action Plan, selecting all non-baseline Action Plans.
In case you're using Sonar > 5.3 (no Action Plan feature), you can instead add a "baseline" Tag to your baseline issues (do it by bulk-changing them).
Once issues have been tagged, you can (from Issues view) filter by Tag, selecting all existings tags but "baseline" tag, and save this Filter, so you don't need to create it every time.
This is exactly what the SonarQube Leak Period is for.
You don't mention your SonarQube server version, so I'll assume the latest: 6.3.
Set Administration > General > Leak > Leak Period to the appropriate value, whether that's a date, previous_version, or a number of days. Then focus solely on "new" metrics, such as Coverage on New Code.
The SonarQube interface is designed to help you focus on Leak Period values by pulling them out into a separate section of the project home page:
I have written a customer annotation processor to generate various source files, wrapped in an Eclipse plugin. As part of this process it also logs various errors and warnings using the usual call ProcessingEnvironment#getMessager().printMesssage(Kind, String, Element).
I have been testing the processor by debugging the plugin in Eclipse. In the launched sub-instance of Eclipse the processor all works as expected - source files are generated, picked up and interpreted by the compiler as desired. Any compiler (i.e. non-custom) errors in the generated and non-generated appear in the editor, Problems view etc. as expected.
However I am seeing a lot of inconsistencies in terms of how custom errors and warnings appear. The behaviour I see is as follows:
If no Element is specified all messages appear in the Error Log under type Info, regardless of the Kind specified when logging the error.
If a message is of Kind NOTE it always appears in the Error Log under type Info, regardless of whether or not an Element is specified.
Otherwise, if an Element is specified errors and warnings intermittently appear in the Problems view and in the editor; sometimes they don't appear anywhere. They never appear in the Error Log, whether the Kind is ERROR or WARNING
As per the emphasis above, the real issue is item 3 - that under certain situations I simply cannot get errors to appear in the editor despite being logged on valid elements. In fact, I have managed to reliably make errors appear and not appear by simply changing the name of a particular generated source file.
Of course the issue is not the filename itself, but it is certainly the case that generating the class with a name that matches references already in code causes errors to get hidden, whilst generating it with a different name (or not at all) causes errors to show (as well as all the regular compiler errors caused by a missing class). The strangest thing is that there is nothing fundamentally different about this generated class compared to any of the others (of which there are many), although it is unique in its structure and how it is referenced. It also reasonably long (around 400 methods), but artificially shortening it did not make any difference. Other generated classes also have existing references in the code and don't suppress errors.
Unfortunately I have also not yet had the time to test if this issue occurs when the Eclipse plugin is deployed (i.e. running in a 'real' instance of Eclipse), or indeed if the issue occurs when calling javac explicitly or invoking a Maven build.
Without posting the full code of the plugin I don't expect anyone to be able to help directly, but I am very open to any suggestions or advice if anybody has experience issues with annotation processor-generated errors. It seems to me like a bug in Eclipse, but I have not been able to find any reference to it online. I also cannot find any errors in the .metadata/.log files of either the underlying Eclipse instance or the launched sub-instance of Eclipse. Finally I have ensured that there are no Exceptions suppressed or reported in the annotation processor code.
Eclipse version details:
Version: Luna Service Release 1a (4.4.1)
Build id: 20150109-0600
Any help appreciated and many thanks in advance :)
If a problem/error has to be shown in the Eclipse Problems view, you need to create a Marker on the particular resource (file/folder/project). Please see the following links on how to create the Markers in an Eclipse Plugin:
https://wiki.eclipse.org/FAQ_How_do_I_create_problem_markers_for_my_compiler%3F
https://www.eclipse.org/articles/Article-Mark%20My%20Words/mark-my-words.html
In terms of how the custom errors/warnings appear, the Problems view (or the generic MarkersView) is completely flexible to show/hide certain elements. Have a look at the "Configure Contents..." menu in the Problems view to get more idea.
I'm one of those guys who step through their code a lot during development. Beginning with version 1.6.4 of the GAE Java development server, the server has been instrumented with calls to a function named Runtime.checkRestricted. This causes two inconveniences when I step through my code:
Whenever I step into a function, the debugger goes into the function Runtime.checkRestricted (for which there is no source code) at least once, often multiple times.
Whenever I step over a function call which has a large call tree underneath, it takes a very long time for the debugger to come back. (That's always a problem in the Eclipse Java debugger, but now it's really bad.)
For me, all this causes a serious drain on productivity. Is there any way to disable this instrumentation, or at least to prevent the debugger from stepping into it? I am using Eclipse with the GAE plugin.
Add a step filter to filter out all step breakpoints you are not interested in. The Eclipse documention provides a guide how to set up step filter.
In your specific case, you will want to add a package filter for com.google.appengine.tools.development.* , as this package and its subpackages contain GAE's Runtime class and RuntimeHelper class. Finally, don't forget to activate the option "Use Step Filters" (Shift + F5).
Is there any plugin to some IDE that show the number of times a line is run in the code?
Eclipse's ECLemma does not seem to have a setting to show execution times at the left-hand-side bar, like in the service WebCat.
I think the eclipse test and performance tools plateform would be able to help you with this. It includes a profiler which will instrument your code and provide the information you want.
Careful with profiling, it can be a heavy performance hit depending on how many functions/classes you monitor
Have a look at the breakpoint properties in eclipse may be you can configure a variable to capture the hitcount
What's wrong with writing to a log file or to screen or using a counter?
The focus of code coverage is only if a line is executed or not. Nothing more.
To get counters you would have to look at profiler software and not code coverage.
There are plugins for both Eclipse and Netbeans. I am not sure if they show counters per line, but I think that they show counters per method, which might be what you want...
(source: free.fr)
In NetBeans 6.8 there is a nice code coverage tool which does pretty much that what you want but actually only for ruby. (right click project -> code coverage)
But could you use an ant task or maven plugin? Then Take a look at this list