javaSpotBugsプラグインの実装方法には公式ドキュメントがありますが、SpotBugsプラグインをSonarQube上で実行するための手法はまだ固まっていません。HelperのSonarQubeプラグインのリリースに動いているので、要点をまとめておきます。SonarQubeプラグイン実装の基本まずSonarQubeの公式ドキュメントに目を通しておきます。Keyの命名に制約があったり、SonarCloudの利用が必須だったりしますので、制約についてよく読んでおくと良いでしょう。Mavenプロジェクトを作るGradleサポートは公式ではないので、Mavenを選択します。SpotBugsプラグインと同じプロジェクトで管理すると、メタデータ作成(後述)で手間がかからないのでおすすめです。私のプロダクトではSpotBugsプラグインとSonarQubeプラグインとをサブモジュールとして管理するプロジェクトを使っています。注意点は以下の通りです:SonarQubeプラグインは<packaging>sonar-plugin</packaging>にする。sonar-packaging-maven-pluginの設定に<basePlugin>findbugs</basePlugin>と<requirePlugins>findbugs:3.5</requirePlugins>を入れる。v3.5は初めてSpotBugsを導入したバージョンなのでこれ以降のバージョンを指定するのが良い。SpotBugsプラグインが何らかのライブラリに依存している場合、普通のパッケージとshadedパッケージと両方を用意すると良い。shadedはAntユーザやCLIユーザなど推移的依存が自動的に解決されない場合(プラグイン手配置が必要な場合)に便利。shadedだけ用意すると、推移的依存が自動的に解決される場合に同じライブラリを複数回ダウンロードするリスクや、dependencyReducedPomによって依存先のメタデータが隠匿されてしまう(例えばライセンス管理がやりにくくなる)問題も生じる。rule.xmlを生成するSonarQubeはfindbugs.xmlやmessages.xmlを読まないので、SonarQubeが読める形式でルールに関するデータを提供する必要があります。私はこれをMavenプラグインで自動生成しています。ルールによってタグを変える必要がある大型プロジェクトじゃない限り、これで十分だと思います。コードを書く基本的にはPlugin.javaとRulesDefinision.javaの2つで足ります。GitHub注意点は以下の通りです:Context#createRepository()の第一引数は"findbugs"である必要がある。それ以外の値だと、sonar-findbugsが検知してくれない。Bugが登録されないので、SpotBugsプラグインが解析に使われても結果一覧に出てこなくなる。Centralに公開した上で、SonarSourceコミュニティのフォーラムで申請すれば通るようです。Contributions(25日時点)でし...2018-08-01dockerでSonarQubeのインストールを楽にやるクラスメソッドさんのブログでSonarQubeの紹介がされています。