sonar java
8.8.0.37665
Ce projet Sonarsource est un analyseur de code pour les projets Java pour aider les développeurs à produire du code propre. Des informations sur l'analyse des fonctionnalités Java sont disponibles ici.
Pour fournir des commentaires (demandez une fonctionnalité, signalez un bogue, etc.) Utilisez le forum de la communauté Sonar. N'oubliez pas de spécifier la langue (Java!), La version du plugin et la version Sonarqube.
Si vous avez une question sur la façon d'utiliser le plugin (et les documents ne vous aident pas), nous vous encourageons également à utiliser le forum communautaire.
Pour demander une nouvelle fonctionnalité, veuillez créer un nouveau fil dans le forum communautaire Sonarqube. Même si vous prévoyez de le mettre en œuvre vous-même et de le soumettre à la communauté, veuillez d'abord démarrer un nouveau fil pour vous assurer que nous pouvons l'utiliser.
Pour soumettre une contribution, créez une demande de traction pour ce référentiel. Veuillez vous assurer que vous suivez notre style de code et tous les tests passent (toutes les vérifications doivent être vertes).
Si vous avez une idée pour une règle, mais que vous n'êtes pas sûr que tout le monde en a besoin, vous pouvez implémenter une règle personnalisée disponible uniquement pour vous. Notez que pour vous aider, nous vous recommandons fortement de suivre d'abord le tutoriel des règles personnalisées 101 avant de plonger directement dans la mise en œuvre des règles à partir de zéro.
Souhaitez-vous travailler sur ce projet à temps plein? Nous embauchons! Consultez https://www.sonarsource.com/hiring
Pour exécuter des tests localement, suivez ces instructions.
Vous avez besoin Java 22 pour construire le projet et Java 17 exécute les tests d'intégration (ITS).
Java 17 peut être utilisé pour construire et tester tous les modules, sauf sous java-checks-test-sources qui nécessite Java 22 .Java 22 peut être utilisé pour construire et tester tous les modules, sauf sous le its qui nécessite Java 17 en raison de l'incompatibilité SQ.Pour construire le plugin et exécuter ses tests unitaires, exécutez cette commande à partir du répertoire racine du projet:
mvn clean install
Les tests unitaires en cours d'exécution dans l'IDE peuvent subir certains problèmes en raison de la façon dont le projet est construit avec Maven. Si vous voyez quelque chose comme ceci:
java.lang.SecurityException: class ... signer information does not match signer information of other classes in the same package
Essayez de retirer la nature maven du module «JDT».
Pour exécuter des tests d'intégration, vous devrez créer un fichier de propriétés comme celui illustré ci-dessous, et définir l'URL pointant vers son emplacement dans une variable d'environnement nommée 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
Avec par exemple la variable ORCHESTRATOR_CONFIG_URL étant définie comme:
export ORCHESTRATOR_CONFIG_URL=file:///home/user/workspace/orchestrator.properties
Avant d'exécuter le IT, assurez-vous que votre variable d'environnement Maven_Home est définie.
Le «test de santé mentale» est un test qui exécute toutes les chèques par rapport à tous les fichiers de source de test sans prendre en compte le résultat de l'analyse. Il vérifie que les règles ne s'écrasent sur aucun fichier dans nos sources de test. Par défaut, ce test est exclu de la construction. Pour le lancer:
mvn clean install -P sanity
Le "test de plugin" est une suite de test d'intégration qui vérifie les fonctionnalités du plugin telles que le calcul métrique, la couverture, etc. pour le lancer:
mvn clean install -Pit-plugin -DcommunityEditionTestsOnly=true
Remarque pour les contributeurs internes: Afin d'exécuter également les tests qui dépendent de l'édition Sonarqube Enterprise, utilisez:
mvn clean install -Pit-plugin
Le "test de décision" est une suite de tests d'intégration qui lance l'analyse d'une grande base de code, enregistre les problèmes créés par le plugin dans les fichiers de rapport, puis compare ces résultats à l'ensemble des problèmes attendus (stockés sous forme de fichiers JSON).
Pour exécuter le test, assurez-vous d'abord que les sous-modules sont vérifiés:
git submodule update --init --recursive
Ensuite, assurez-vous que la variable d'environnement JAVA_HOME est définie pour l'exécution des tests de décision et qu'il pointe vers votre installation JDK 17 locale. Ne pas le faire produira des incohérences avec les résultats attendus.
À partir du dossier its/ruling , lancez les tests dirigeants:
mvn clean install -Pit-ruling -DcommunityEditionTestsOnly=true
# Alternatively
JAVA_HOME=/my/local/java17/jdk/ mvn clean install -Pit-ruling -DcommunityEditionTestsOnly=true
Remarque pour les contributeurs internes: Afin d'exécuter également les tests qui dépendent de l'édition Sonarqube Enterprise, utilisez:
mvn clean install -Pit-ruling
Ce test vous donne la possibilité d'examiner les problèmes créés par chaque règle et de vous assurer qu'ils attendent. Toute règle implémentée est très susceptible de soulever des problèmes sur les multiples projets que nous utilisons comme base de code dominante.
Pour une règle nouvellement mise en œuvre, cela signifie qu'une première version échouera très probablement, causée par des différences entre les résultats attendus (sans aucune valeur pour la nouvelle règle) et les nouveaux résultats. Vous pouvez inspecter ces nouveaux problèmes en recherchant des fichiers nommés d'après votre règle ( squid-SXXXX.json ) dans le dossier suivant:
/path/to/project/sonar-java/its/ruling/target/actual/...
Pour les règles existantes qui sont modifiées, vous pouvez vous attendre à certaines différences entre les résultats "réels" (de nouvelles analyses) et les résultats attendus. Passez en revue soigneusement les modifications affichées et mettez à jour les ressources attendues en conséquence.
Tous les fichiers json contiennent une liste de lignes, indexée par le fichier, expliquant où se trouvent les problèmes soulevés par une règle spécifique. Si / quand tout vous semble bien, vous pouvez copier le fichier avec les problèmes réels situés à:
its/ruling/target/actual/
Dans le répertoire avec les problèmes attendus:
its/ruling/src/test/resources/
Par exemple en utilisant la commande:
cp its/ruling/target/actual/* its/ruling/src/test/resources/
Les tests du module Autoscan sont conçus pour détecter les différences entre les problèmes que l'analyseur Java peut trouver avec et sans bytecode. L'objectif ici est de repérer et de réparer les FP potentiels, et de vérifier les FN attendus entre cela apparaîtrait dans l'analyse automatique de SonarCloud.
L'exécution de ce test peut être décomposée en 2 étapes:
Assurez-vous que le module java-checks-tests-sources a été compilé (c'est-à-dire: les fichiers .class dans java-checks-tests-sources/target/ sont à jour).
En doute, allez le module java-checks-tests-sources et exécutez:
# Use java 22!
mvn clean compile Pour exécuter les tests, passez au dossier its/autoscan et exécutez:
# cd its/autoscan
# use Java 17!
mvn clean package --batch-mode --errors --show-version
--activate-profiles it-autoscan
-Dsonar.runtimeVersion=LATEST_RELEASE Les artefacts produits lors de l'exécution du test se trouvent dans its/autoscan/target/actual . Vous voudrez comparer les résultats produits dans l'Autoscan-Diff-by-Rules
Pour des informations plus détaillées, vous pouvez comparer les différences entre les résultats trouvés avec ByteCode et sans ByteCode en comparant deux dossiers respectifs:
Selon les résultats trouvés, vous devrez peut-être mettre à jour la vérité au sol. Les résultats attendus sont répertoriés dans SRC / Test / Ressources.
Vous pouvez déboguer en ajoutant -Dmaven.binary=mvnDebug en option lors de l'exécution des tests. Cela amènera l'analyseur JVM à attendre qu'un débogueur soit attaché avant de continuer.
Copyright 2012-2024 Sonarsource.
Les analyseurs de SonarQube publiés après le 29 novembre 2024, y compris les correctifs de correctifs pour les versions antérieures, sont publiés sous la version 1 à la licence disponible sur la source sonar (SSALV1).
Voir les fichiers individuels pour plus de détails qui spécifient la licence applicable à chaque fichier. Les fichiers soumis au SSALV1 seront notés dans leurs en-têtes.
