SonarQube提供了独立的log服务，命令行启动时输出的是sonar.log的内容。上述Netty4Transport exception caught on transport layer远程连接关闭的问题log属于es.log(elastic search)的部分。
而由于自定义规则的plugin导致的问题会在ce.log(Compute Engine)里有具体的提示（但这个内容居然不在命令行输出，导致一直对上面的远程连接失败摸不着头脑）。基本会有类似——
org.sonar.updatecenter.common.exception.IncompatiblePluginVersionException: The plugin 'java' is in version 5.10.1.16922 whereas the plugin 'javacustom' requires a least a version 6.3.0.21585.
猜测没错，属于兼容性问题。关键的两个版本值——
-
sonar.version的值为plugin支持的SonarQube最低版本（目前8.0以上对应的LTS版本为7.9；目前看7.6根7.7还是兼容的）。最新的兼容矩阵在7.9以下版本里没有对应的说明。 -
sonarjava.version对应plugin支持的版本，需要跟使用的SonarQube中安装的版本一致，管理员登录后，可以在admin/marketplace?filter=installed位置查看SonarJava的版本。
根据pom.xml的git log对其他的依赖进行对应的修改。
# current
<sonar.version>8.2.0.32929</sonar.version>
<sonarjava.version>6.3.0.21585</sonarjava.version>
# modify
<sonar.version>7.7</sonar.version>
<sonarjava.version>5.10.1.16922</sonarjava.version>
回滚到上述版本后，目前的测试方法都失效了。——这是因为org.sonar.java.checks.verifier.JavaCheckVerifier的 public static CheckVerifier newVerifier()方法在2020/3/17加入的。SONARJAVA-3315 Unify CheckVerifiers accross the plugin (#2871)e7f1493fa8572fa88ed528be37fc8debabc5e671
此时本地再执行单元测试时，会报错——
The rule 'f.newTuple20(Object, Object)' has already been defined somewhere in the grammar.
这两个地方都讨论了这个问题：
本地测试无法正常运行（环境改的比较多了），但不影响打包操作。mvn clean install可以正常生成jar包。
放到对应的位置，重启SonarQube，可以看到这个自定义的plugin——
