对于sonar的安装，笔记并未做相关记录，原因很简单，百度一下你就知道；
笔记着重自定义规则开发，个人也是慢慢摸索，一路坎坷，接下来一点点分享，欢迎各路大神批评指正：
1.针对于sonarqube的自定义规则开发，这边是通过IDEA来搭建的环境，对于源码阅读比较舒服。
2.从官方下载了自定义规则的demo，这也就可以开始玩起来。
结构树如图：
该类实现了接口Plugin
那么接下来对这个接口分析：
里面只有一个define方法，同时该方法的入参被封装成了一个静态内部类，ok，接下来继续分析：
在这个静态内部类中定义了一些方法，观察发现，这些方法都是为内部的两个final的参数服务的，足见两个参数的重要，那就一起看看这两个参数吧
关于第一个SonarRuntime，一个接口
通过类图发现，只有一个子类SonarRuntimeImpl ， （够神奇的，就一个类还用一个接口去抽象替换实体，不过细想就回发现这样做肯定是为了后期对于sonarqube的相关配置和服务升级，同时也保证了java的开闭原则，此处略略略。。。） 进入子类看看
这里分析应该是和qube服务器相关的设置，对于自定义规则不太感冒，后续在继续研究，返回之前对Plugin的内部静态类的第二个参数： private final List extensions = new ArrayList();
上边说的第二个参数如图：
该参数extensions结构是哪个方法和插件入口类中的两个add方法
发现，其目的就是把容器自定义的参数封装到sonar容器中
下图是入口类的图，上文也有，为了方便阅读，再次复制过来
是不是都指向了内部的方法，哈哈，接下来对传入的这两个类逐一分析：
MyJavaRulesDefinition 类主要是对视图方面的加载，此处后期补充
MyJavaFileCheckRegistrar： 这个类 ，很有味道，当然也是我们需要着重关心的
结合三张图，你也可以自己去看看，Ruleslist是一个静态工具类，我理解为工厂，不过这里的工厂貌似就是个打包机器，把所有自定义的规则打包到里面，这里有一个特别的地方就是ImmutableList这个容器类的使用，是一个对集合可变性的工具拓展类，谷歌推出的guava工具包，这个工具包之前听说是被jdk8融进来了，此处略过继续略过。。
ok 这些分析结束，后面的就是easy的事情了
自定义规则：
这里随机挑选了一个短一些的代码分析：
这是一个堆类名的规则校验自定义类，类名上有注释，可以阅读：
package org.sonar.samples.java.checks;
import com.sun.xml.internal.ws.api.model.JavaMethod;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
import org.sonar.check.Rule;
import org.sonar.plugins.java.api.JavaFileScanner;
import org.sonar.plugins.java.api.JavaFileScannerContext;
import org.sonar.plugins.java.api.tree.*;
/**
* 抽象类命名检查
* 抽象类命名使用 Abstract 或 Base 开头
*
*/
@Rule(key = "AbstractClassNameCheck")
public class AbstractClassNameCheck extends BaseTreeVisitor implements JavaFileScanner{
private static final Logger LOGGER = LoggerFactory.getLogger(AbstractClassNameCheck.class);
private JavaFileScannerContext context; //用于存储上下文的私有字段：这是用于创建问题的对象
private JavaMethod method;
@Override
public void scanFile(JavaFileScannerContext context) {
this.context = context;
scan(context.getTree());
}
@Override
public void visitClass(ClassTree tree) {
String className = tree.simpleName().name();
LOGGER.info(" : " +tree.firstToken().line());
LOGGER.info(tree.simpleName().name() + "------ " + tree.symbol().isAbstract());
if(tree.symbol().isAbstract()){
//判断名称是否以Abstract 或 Base 开头
String abName = "Abstract";
String bsName = "Base";
//判断类名如果小于Abstract 或 Base
if (className.length() < abName.length() || className.length() < bsName.length()) {
context.reportIssue(this, tree, "抽象类的名称应首先使用Abstract或Base");
context.addIssue(tree.firstToken().line(),this,"有点味道儿..");
} else {
//判断是否存在 Abstract 或 Base
if (!className.contains(abName)) {
if (!className.contains(bsName)) {
context.reportIssue(this, tree, "抽象类的名称应首先使用Abstract或Base");
context.addIssue(tree.firstToken().line(),this,"有点味道儿..");
} else {
if (className.indexOf(bsName) != 0) {
context.reportIssue(this, tree, "抽象类的名称应首先使用Abstract或Base");
context.addIssue(tree.firstToken().line(),this,"有点味道儿..");
}
}
} else {
if (className.indexOf(abName) != 0) {
context.reportIssue(this, tree, "抽象类的名称应首先使用Abstract或Base");
context.addIssue(tree.firstToken().line(),this,"有点味道儿..");
}
}
}
}
super.visitClass(tree);
}
@Override
public void visitMethod(MethodTree tree) {
LOGGER.info("Me : "+tree.symbol().name());
if (tree.symbol().name().equals("test1")) {
LOGGER.info("xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx");
context.reportIssue(this,tree,"方法有味道。。。");
}
super.visitMethod(tree);
}
}
解读自定义规则：
通过注解@Rule 来定义规则的key名
该注解可以有如上图的这些参数
在自定义规则类中，需
extends BaseTreeVisitor implements JavaFileScanner
而对于这两个类，一个是扫描文件，一个是将文件中的内容封装为各个语法树，同时各个语法树也可以拆借为开头语法，结束语法，在定义规则是分别可以拿到相应文段的左边，行号，列号以及内容，通过对坐标内容的比对，来 完成自定义规则的实现
当然还有一个类比较有意思，这里后面用到会继续分析
public static enum Kind implements GrammarRuleKey 这个枚举封装了java文件中所有的相关信息的类信息，比如字段是方法还是变量 ，是静态的吗 等等 ， 都是返回该枚举中的一个，通过比对也可以实现一些自定义规则
