What's the correct way to write custom checks for SonarQube 4.5
Currently, the best way to write SonarQube 4.5 is for:
- Bytecode analysis
- Initial analysis
Unfortunately I was unable to find an updated web page with a clear explanation, and I see that existing checks use many deprecated classes and methods, use bridges that should be left out, checks are regularly removed from the codebase (for example, the XPath rule ).
I would like to make sure that the checks I am about to write will be well written and durable.
So...
- to use
BytecodeVisitor
for parsing bytecode? - to use
BaseTreeVisitor
to analyze the source code? - What replaces
org.sonar.api.rules.RuleRepository
? - What is a replacement for
org.sonar.api.resources.Java
? - What is a replacement
org.sonar.api.rules.AnnotationRuleParser
? - How to write rules like XPath (
BaseTreeVisitor
uses SSLR and if I'm not mistaken SonarQube departs from SSLR /AbstractXPathCheck
is part of the sslr squid bridge.) - What else should I know?
In other words, I lost a little.
Thank you in advance for your help.
source to share
First thanks for your feedback, there are actually a lot of questions in your question:
The way to write custom checks for Java today is to use BaseTreeVisitor
. All other methods are now deprecated, and we are working on removing them (but this is not always easy, since some of them require a complete analysis of the semantics). What is currently missing from this api is access to semantic analysis to be able to query the type information read from the bytecode. You can take a look at this project: https://github.com/SonarSource/sonar-examples/tree/master/plugins/java-custom-rules
For all other questions, please ask on the mailing list.
(Small notes: BaseTreeVisitor does not use SSLR directly, the java plugin does not depart from SSLR and not from a single class, specifically ASTNode
to work with SyntaxTree with a class defined for each node type. In this logic, the transition from the non-printable syntax Tree fails Xpath.
source to share