sonar java
8.8.0.37665
このSonarsourceプロジェクトは、開発者がクリーンなコードを作成するのに役立つJavaプロジェクトのコード分析装置です。 Java機能の分析に関する情報はこちらから入手できます。
フィードバックを提供するには（機能をリクエストし、バグをレポートするなど）、Sonarコミュニティフォーラムを使用します。言語（Java！）、プラグインバージョン、Sonarqubeバージョンを指定することを忘れないでください。
プラグインの使用方法について質問がある場合（およびドキュメントは役に立たない）、コミュニティフォーラムを使用することもお勧めします。
新しい機能をリクエストするには、Sonarqubeコミュニティフォーラムで新しいスレッドを作成してください。自分で実装してコミュニティに送信する予定がある場合でも、まず新しいスレッドを開始して、使用できることを確認してください。
寄付を送信するには、このリポジトリのプルリクエストを作成します。コードスタイルに従い、すべてのテストが合格していることを確認してください（すべてのチェックは緑でなければなりません）。
あなたがルールのアイデアを持っているが、誰もがそれを必要とするかどうかわからない場合、あなただけが利用できるカスタムルールを実装できます。お客様を支援するために、最初にカスタムルール101チュートリアルに従って、ゼロからルールを実装する前に直接飛び込むことを強くお勧めします。
このプロジェクトにフルタイムで取り組みたいですか？私たちは雇っています！ https://www.sonarsource.com/hiringをご覧ください
テストを実行するには、これらの指示に従います。
プロジェクトを構築するにはJava 22必要であり、 Java 17統合テスト（ITS）を実行します。
Java 17 Java 22を必要とするjava-checks-test-sourcesを除くすべてのモジュールを構築およびテストするために使用できます。Java 22 SQの非互換性のためにJava 17を必要とするits下を除くすべてのモジュールを構築およびテストするために使用できます。プラグインを構築してユニットテストを実行するには、プロジェクトのルートディレクトリからこのコマンドを実行します。
mvn clean install
IDE内でユニットテストを実行すると、プロジェクトがMavenで構築される方法があるため、いくつかの問題で発生する可能性があります。あなたがこのようなものを見たら：
java.lang.SecurityException: class ... signer information does not match signer information of other classes in the same package
「JDT」モジュールのMaven性を削除してみてください。
統合テストを実行するには、以下に示すようなプロパティファイルを作成し、URLをORCHESTRATOR_CONFIG_URLという名前の環境変数の位置に向けて設定する必要があります。
# version of SonarQube Server
sonar.runtimeVersion=LATEST_RELEASE
orchestrator.updateCenterUrl=http://update.sonarsource.org/update-center-dev.properties
# The location of the Maven local repository is not automatically guessed. It can also be set with the env variable MAVEN_LOCAL_REPOSITORY.
maven.localRepository=/home/myName/.m2/repository
たとえば、 ORCHESTRATOR_CONFIG_URL変数は次のように設定されています。
export ORCHESTRATOR_CONFIG_URL=file:///home/user/workspace/orchestrator.properties
ITSを実行する前に、Maven_home環境変数が設定されていることを確認してください。
「Sanity Test」は、分析の結果を考慮せずに、すべてのテストソースファイルに対してすべてのチェックを実行するテストです。テストソースのファイルでルールがクラッシュしていないことを確認します。デフォルトでは、このテストはビルドから除外されます。起動するには：
mvn clean install -P sanity
「プラグインテスト」は、メトリック計算、カバレッジなどのプラグイン機能を検証する統合テストスイートです。
mvn clean install -Pit-plugin -DcommunityEditionTestsOnly=true
内部貢献者向けの注意：Sonarqube Enterprise Editionに依存するテストも実行するために、以下を使用してください。
mvn clean install -Pit-plugin
「ルーリングテスト」は、大きなコードベースの分析を開始し、Reportファイルのプラグインによって作成された問題を保存し、それらの結果を一連の予想問題（JSONファイルとして保存）と比較する統合テストスイートです。
テストを実行するには、最初にサブモジュールがチェックアウトされていることを確認してください。
git submodule update --init --recursive
次に、 JAVA_HOME環境変数が与党テストの実行に設定されていることを確認し、ローカルJDK 17のインストールを指していることを確認します。そうしないと、予想される結果と矛盾が生じます。
its/rulingフォルダーから、支配テストを起動します。
mvn clean install -Pit-ruling -DcommunityEditionTestsOnly=true
# Alternatively
JAVA_HOME=/my/local/java17/jdk/ mvn clean install -Pit-ruling -DcommunityEditionTestsOnly=true
内部貢献者向けの注意：Sonarqube Enterprise Editionに依存するテストも実行するために、以下を使用してください。
mvn clean install -Pit-ruling
このテストは、各ルールによって作成された問題を調べ、それらがあなたが期待していることを確認する機会を提供します。実装されたルールは、支配コードベースとして使用する複数のプロジェクトで問題を提起する可能性が高くなります。
新たに実装されたルールの場合、最初のビルドは、予想される結果（新しいルールの値なし）と新しい結果の違いによって引き起こされる可能性が高いことを意味します。次のフォルダーでルール（ squid-SXXXX.json ）にちなんで名付けられたファイルを検索することで、これらの新しい問題を検査できます。
/path/to/project/sonar-java/its/ruling/target/actual/...
変更された既存のルールの場合、「実際の」（新しい分析から）と予想される結果の違いが期待される場合があります。表示される変更を注意深く確認し、それに応じて予想されるリソースを更新します。
すべてのjsonファイルには、ファイルごとにインデックスが付けられた行のリストが含まれており、特定のルールによって提起された問題がどこにあるかを説明しています。すべてがあなたに良く見える場合、あなたは次のような実際の問題でファイルをコピーできます：
its/ruling/target/actual/
予想される問題があるディレクトリに：
its/ruling/src/test/resources/
たとえば、コマンドの使用：
cp its/ruling/target/actual/* its/ruling/src/test/resources/
Autoscanモジュールのテストは、JavaアナライザーがBytecodeの有無にかかわらず見つけることができる問題の違いを検出するように設計されています。ここでの目標は、潜在的なFPSを見つけて修正し、SonarCloudの自動分析に表示される予想されるFNSを検証することです。
このテストの実行は、2つのステップで分解できます。
java-checks-tests-sourcesモジュールがコンパイルされていることを確認してください（つまり、 java-checks-tests-sources/target/の.classファイルが最新です）。
疑わしいことに、 java-checks-tests-sourcesモジュールに移動して実行します。
# Use java 22!
mvn clean compileテストを実行するには、 its/autoscanフォルダーに移動して実行します。
# cd its/autoscan
# use Java 17!
mvn clean package --batch-mode --errors --show-version
--activate-profiles it-autoscan
-Dsonar.runtimeVersion=LATEST_RELEASEテスト実行中に生成されたアーティファクトはits/autoscan/target/actualに見られます。 Autoscan-Diff-by Ruleで生成された結果を比較したいと思うでしょう
詳細については、2つのそれぞれのフォルダーを比較して、ByteCodeおよびByteCodeなしで見つかった結果の違いを比較できます。
見つかった結果に応じて、グラウンドトゥルースを更新する必要がある場合があります。予想される結果は、SRC/テスト/リソースにリストされています。
テストを実行するときにオプションとして-Dmaven.binary=mvnDebugを追加することで、デバッグできます。これにより、アナライザーJVMは、継続する前にデバッガーが添付されるのを待つようになります。
Copyright 2012-2024 Sonarsource。
2024年11月29日以降にリリースされたSonarqubeアナライザーは、以前のバージョンのパッチ修正を含む、SONARソース利用可能なライセンスバージョン1（SSALV1）で公開されています。
各ファイルに適用されるライセンスを指定する詳細については、個々のファイルを参照してください。 SSALV1の対象となるファイルは、ヘッダーに記録されます。
