I'm working for a client that wants SonarLint used on their projects. Their IDE of choice is Eclipse. They do not have SonarQube. What I am looking for is a way to clear out the SonarLint annotation for a particular instance of a rule violation, rather than disabling the rule altogether.
For example, the rule about removing commented out code is useful for finding code accidentally left behind after testing, but there are occasions where commented out code is left behind because the business is not yet clear on how they want a particular routine to function. It would be helpful to be able to clear that one instance of the rule violation annotation.
Is this even possible without SonarQube?
You should add on your code an annotation with the specific rule id, and add a comment to explain, e.g. :
#SuppressWarnings("squid:CommentedOutCodeLine") //code commented out because business is not yet clear
Related
I'm trying to ignore Lombok code (generated code) from Sonar analysis based on files which have a custom annotation, #ExcludeLombok.
I've tried this guide which did not work.
In fact, I've even tried excluding an entire directory from analysis and it still wouldn't work.
I've also tirelessly searched through StackOverflow looking for a solution, and I've seen this has been discussed a good bit on here, but I've seen that people have been suggesting to write a single test to get the coverage up, which is pointless since we should not test auto generated code.
The solution I'm looking for is to exclude files based on a custom annotation.
But so far, anything I attempt to exclude does not get excluded.
Any help would be greatly appreciated.
There is currently no easy way to exclude issues raised by the SonarQube rules from the SonarQube Java Analyzer, except from using approaches described in the "Narrowing the focus" documentation you quote.
Now, we introduced recently the concept of issue filters in the SonarQube Java Analyzer. This mechanism is at the moment only used internally to exclude issues raised by rules at analysis time, based on specific criteria.
We plan to extends this mechanism in order to allow users to implements their own custom issue filters, the same way custom rules can be implemented. This approach would cover your case and allow you to filter any rules on code annotated with your custom annotation. This new feature will be handled in the following JIRA ticket: SONARJAVA-1761
Another option you have is to run Sonar over delomboked source. There are various ways to delombok depending on your build system see:
Delombok Overview.
For maven there's an example of running analysis on delomboked code: Delombok test pom
In each case you would make sure you ran the checks over generated source.
Currently, I am working in a new project and it was difficult for me to understand since there is no comment. I wonder if it is possible to force team members(including me) to add more comments. I would like to automate this ject in jenkins later if possible.
You can run static code checks and their corresponding eclipse plug-ins to enforce comments being made in code.
For e.g. in CheckStyle javadoc can be enforced http://checkstyle.sourceforge.net/config_javadoc.html
Also checkstyle can be easily integrated with Jenkins.
You can also use eclipse java compiler settings for javadoc check.
Go to preferences->java->compiler->javadoc to enforce errors and warnings.
Compiler errors and warnings can be easily reported through continuous build
cheers,
Saurav
I can only recommend to be very, very careful with that. Of course, you may use tools like SONAR, Eclipse Settings and the like to enforce comments.
Buuuuuuuut:
You can easily generate comments (/w Eclipse) and -as you probably
know- generated comment is not use/helpful at all.
In case you add a useful comment and it relies too much on the actual implementation, you also have to maintain it. Whenever the code changes you need to validate if the comment does too. This is often overlooked and creates more confusion then by not having any comment at all. Even though you had a good intention in the first place.
"The Truth Lies In The Code"(tm): You can achieve good to understand and easy maintainable code by working very hard on it. This might help to avoid to need any comment at all. Its not easy (and not always possible), I admit that.
At least "public API" must be documented. That could be a rule of thumb and it seems managable in a large code base.
I would rather spend more time in having good understandable code instead of "forced comments". You may achieve the complete opposite by enforcing it.
Using Sonar/Eclipse Settings to enforce documentation of public API makes sense to me though.
This needs to be implemented at the source control level, not the IDE level.
If you're using git, you can look into git hooks http://git-scm.com/docs/githooks
This will let you write little scripts that will be run when you commit code. You can write a script to check if the commit includes a valid comment. You can also perhaps allow skipping of comments with a "-force" option or something like that.
I'm working on a plugin which editor augments on the existing JDT (Java) editor
using aspects.
Now, Eclipse text editors that derive from AbstractTextEditor are
organized in clear components, following an MVC architecture. Those
components are then accessed through precise paths,
e.g. reconciliation. You can find one example of a custom reconciler and
the assumptions it can (and does) use on the behavior of the editor
here.
I'd like to write headless unit tests against those assumptions, that
would check that my weaving through aspects has not broken anything along
the way. For example, in the case of reconciliation, I would like to
open an editor, input some incorrect content (with respect to some
reconciliation strategy), wait for a while, and check that Problems are
indeed reported.
Note that which problems are reported, or how they would be signaled to
the user in a UI component doesn't concern me : I want
to test that my swapping a SourceViewer for a custom one through aspects
doesn't break editor logic, not my specific reconciliation strategy.
(In fact, I'd
probably mock it for that test. Moreover, the UI testing, being
presumably not runnable in a headless fashion, is beyond the scope of my
question.)
It seems this should be easy to do if the appropriate structures
existed. Do they ? Is there any test framework or mocks in sync with Eclipse's
architectural assumptions that would let me do what I have in mind ? Those would have to reproduce workflow behavior of the existing Eclipse editor. Surely this would be among Eclipse's own unit tests, right ? ... though
I can't seem to find anything of the sort. Any ideas ?
I have asked that same question on the eclipse core platform mailing-list, and got a great answer from Dani Megert giving me pointers to Eclipse's own test framework. The Junit plugin tests are released for download as part of the extended SDK, and browsing the git source lets you see there are already tests against the model or interacting with some of the Editor components.
I have the following problem.
I am working on a new Stuts2 project which is half way done.
The action classes are annotated, and not XML configured. My problem is: it is very difficult to find the class an action is mapped to.
Is there any way to jump to the class where the action is executed?
Example:
in the JSP i have following code:
<s:url var="ajax" value="/ajax1.action" />
How can I very quickly find the action class this action is mapped to.
My project has more than 500 classes.
I am using Eclipse Indigo.
Unless you use a Struts 2 plugin that tracks annotations (e.g., IntelliJ, MyEclipse) you'll need to search.
IMO this problem is a non-issue if you have named your actions in a logical, consistent fashion: finding functionality should be easy even without IDE support. This takes some time and thought during the development process, but pays dividends in the long run.
AFAIK the only option is to search for it. You can do a global search in Eclipse Ctrl+H -> File Search.
These are the options we have out of the box:
I would like a more fine grained sorting when it comes to methods. I would like to:
Have all methods with a name which does not start with get, is or set first.
Then have the accessor methods (with names starting with get, is or set).
Individually the methods in [1] and [2] above could be sorted in alphabetical order. Apart from my devision of normal methods into two parts I like the existing sort order.
I find this order (with the accessor methods last) better as I'm more likely to find the non-accessor methods interesting when I'm maintaining a class and I need to fix a bug etc.
Is there a plugin I could use? If there is none, would it be hard to create this kind of plugin myself? (I have never created a Eclipse plugin.)
I hope it's not to late for my answer.
As far as I know, there is no such plugin (I looked at eclipse plugin central right now).
If you want to write such plugin, it shouldn't be too hard to write the refactoring (the Java Editor is based on an AST, that can be reached via extension points) itself, but for building a working plugin it might need more study.
Some resources that might help:
Plugin development resources from stackoverflow: question 592391 (sorry, but cannot post two hyperlinks)
An open source refactoring plugin: http://code.google.com/p/tane/ (it currently contains a single refactoring plus the related gui elements, it might be a good example for you)
In 2011, an academic exercise resulted in an Eclipse plugin implementing methods sorting based on ideas in Robert C. Martin's book "Clean Code". I am still trying to work out if I like it or not.
There is an open bug report to enhance sort member functionality in Eclise: Sort Members doesn't provide a means to group getter/setter pairs. It was opened in 2004 and still has no plans to be implemented.