SonarQube de mise à niveau à partir de 6.4 6.5 rompt le scanner

  1. Je suis sur sonarQube6.4 et ont mis à jour 6.5
  2. Sonar-scanner est 3.0.3
  3. Maintenant, après la mise à niveau, le scanner ne parvient pas à tout moment il y a un fichier java dans le chemin de la source. Si je ne scanne pas les fichiers java tout fonctionne bien.
  4. Cependant, Si je la restauration d'une utilisation 6.4 version, tout fonctionne bien, donc, il y a une régression? C'est la trace de la pile, lorsque je lance le scanner de commande avec -X commande. Ainsi est-il un mandat de 6,5 à condition que l'emplacement de tous compilés classé, il est un moyen de l'ignorer.

04:56:21.218 DEBUG: Capteurs : JavaSquidSensor -> SurefireSensor ->
JaCoCoSensor -> SonarJavaXmlFileSensor -> Analyseur "de php.ini" fichiers
-> aucune Couverture Capteur -> DPC Bloc de l'Indexeur 04:56:21.218 INFO: Capteur JavaSquidSensor [java] 04:56:21.558 INFO: Configuré source Java
version (sonar.java.source): aucun 04:56:21.565 INFO: JavaClasspath
initialisation 04:56:21.570 INFO:
------------------------------------------------------------------------ 04:56:21.571 INFO: ÉCHEC DE L'EXÉCUTION DE 04:56:21.571 INFO:
------------------------------------------------------------------------ 04:56:21.571 INFO: temps Total: 6.545 s 04:56:21.707 INFO: la Finale de la Mémoire:
51M/1083M 04:56:21.707 INFO:
------------------------------------------------------------------------ 04:56:21.707 ERREUR: Erreur lors de SonarQube Scanner exécution
org.sonar.squidbridge.l'api.AnalysisException: Veuillez fournir compilé
les classes de votre projet avec sonar.java.les binaires de la propriété
au org.sonar.java.JavaClasspath.init(JavaClasspath.java:59)
au org.sonar.java.AbstractJavaClasspath.getElements(AbstractJavaClasspath.java:281)
au org.sonar.java.SonarComponents.getJavaClasspath(SonarComponents.java:141)
au org.sonar.java.JavaSquid.(JavaSquid.java:83)
au org.sonar.les plugins.java.JavaSquidSensor.execute(JavaSquidSensor.java:83)
au org.sonar.scanner.le capteur.SensorWrapper.analyser(SensorWrapper.java:53)
au org.sonar.scanner.les phases.SensorsExecutor.executeSensor(SensorsExecutor.java:88)
au org.sonar.scanner.les phases.SensorsExecutor.execute(SensorsExecutor.java:82)
au org.sonar.scanner.les phases.SensorsExecutor.execute(SensorsExecutor.java:68)
au org.sonar.scanner.les phases.AbstractPhaseExecutor.execute(AbstractPhaseExecutor.java:78)
au org.sonar.scanner.la numérisation.ModuleScanContainer.doAfterStart(ModuleScanContainer.java:179)
au org.sonar.de base.la plate-forme.ComponentContainer.startComponents(ComponentContainer.java:144)
au org.sonar.de base.la plate-forme.ComponentContainer.execute(ComponentContainer.java:129)
au org.sonar.scanner.la numérisation.ProjectScanContainer.scan(ProjectScanContainer.java:261)
au org.sonar.scanner.la numérisation.ProjectScanContainer.scanRecursively(ProjectScanContainer.java:256)
au org.sonar.scanner.la numérisation.ProjectScanContainer.doAfterStart(ProjectScanContainer.java:245)
au org.sonar.de base.la plate-forme.ComponentContainer.startComponents(ComponentContainer.java:144)
au org.sonar.de base.la plate-forme.ComponentContainer.execute(ComponentContainer.java:129)
au org.sonar.scanner.de la tâche.ScanTask.execute(ScanTask.java:47)
au org.sonar.scanner.de la tâche.TaskContainer.doAfterStart(TaskContainer.java:84)
au org.sonar.de base.la plate-forme.ComponentContainer.startComponents(ComponentContainer.java:144)
au org.sonar.de base.la plate-forme.ComponentContainer.execute(ComponentContainer.java:129)
au org.sonar.scanner.bootstrap.GlobalContainer.executeTask(GlobalContainer.java:119)
au org.sonar.lot.programme d'amorçage.Lot.executeTask(Lot.java:116)
au org.sonarsource.scanner.api.internal.batch.BatchIsolatedLauncher.execute(BatchIsolatedLauncher.java:63)
au coucher du soleil.de réfléchir.NativeMethodAccessorImpl.invoke0(Native method)
au coucher du soleil.de réfléchir.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
au coucher du soleil.de réfléchir.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
à java.lang.de réfléchir.La méthode.invoke(la Méthode.java:498)
au org.sonarsource.scanner.l'api.interne.IsolatedLauncherProxy.invoke(IsolatedLauncherProxy.java:60)
au com.soleil.proxy.$Proxy0.execute(Source Inconnue)
au org.sonarsource.scanner.l'api.EmbeddedScanner.doExecute(EmbeddedScanner.java:233)
au org.sonarsource.scanner.l'api.EmbeddedScanner.runAnalysis(EmbeddedScanner.java:151)
au org.sonarsource.scanner.cli.Principal.runAnalysis(Principale.java:123)
au org.sonarsource.scanner.cli.Principal.execute(Principale.java:77)
au org.sonarsource.scanner.cli.Principal.principale(Main.java:61) 04:56:21.710 DEBUG: Exécution getVersion 04:56:21.711 DEBUG: Exécution
arrêter

Quand je lance la même chose avec 6.4, il fonctionne très bien et le seul avertissement que je vois dans la console :

04:52:42.738 attention: le Bytecode de dépendances n'a pas été fournies pour l'analyse des fichiers source, vous pourriez vous retrouver avec des résultats moins précis. Le Bytecode peut être fournie à l'aide d'un sonar.java.les bibliothèques de la propriété

La version du plugin est important, semble vos deux SonarQube peut exécuter un autre SonarJava version.
D'accord, en 6.4 il est sonar-java-plugin-4.9.0.9858.jar tandis que dans 6.5 il est sonar-java-plugin-4.12.0.11033.jar mais je crois que c'est une régression, où, avec le nouveau plugin pour mandat de fournir l' .classe d'emplacement des fichiers. Je souhaite qu'il y est une option pour le remplacer

OriginalL'auteur Prashant Saddi | 2017-08-20

  1. 16

    Erreur lors de SonarQube Scanner exécution
    org.sonar.squidbridge.l'api.AnalysisException: Veuillez fournir compilé
    les classes de votre projet avec sonar.java.les binaires de la propriété

    Depuis SonarJava 4.12, vous devez spécifier le sonar.java.les binaires de la propriété https://docs.sonarqube.org/display/PLUG/Java+le Plugin+et+Bytecode

    Exemple :

    sonar-scanner -Dsonar.projectKey=fr.demo:my-project -Dsonar.sources=. -Dsonar.java.binaries=.
    Vous êtes à la vie de veille et le temps de veille. 🙂 Merci @gujou C'est -Dsonar.java.les binaires=.

    OriginalL'auteur gujou

  2. 1

    Le message d'erreur dit:

    Error during SonarQube Scanner execution org.sonar.squidbridge.api.AnalysisException:
Please provide compiled classes of your project with sonar.java.binaries property

    Il semble que le java capteur nécessite la .class fichiers, en plus de la .java fichiers.

    Vous pouvez:

    • Ajouter ces fichiers à l'analyse (il sera par la façon dont vous donner plus de valeur sonar résultats!)
    • Essayez d'ajouter et de supprimer des fichiers pour trouver quel morceau de code à l'origine du problème et le signaler comme un Sonar bug de Java
    Salut, Merci pour votre temps. Je suis d'accord, les résultats de l'analyse serait plus exact, avec le pseudo-code d'accès. Toutefois, le fait est que nous n'avons pas de contrôle de version des fichiers de classe dans GIT, de sorte que lorsque nous l'invoquons comme un simple déclencheur avec le contrôle de version, il n'y a pas d'accès à ces .classes et donc il se casse maintenant, contrairement à 6.4
    Pourriez-vous exécuter l'analyse sur la même machine qui exécute la compilation de votre code?
    Je suis en train d'essayer d'utiliser de la SQ dans le cadre de jenkins s'appuie donc, cela dépend de la manière dont les utilisateurs ont de l'installation de leur sonar propriétés. Je suis très sûr que ils n'ont pas cette propriété, de sorte que demander de 100 différentes équipes pour apporter des modifications à leur emploi pourrait ne pas être facile, alors peut-être nous attendre une future version qui permet à l'emplacement des binaires pour être en option

    OriginalL'auteur slartidan

  3. 0

    Même j'ai été également confrontés à la même question après SonarQube passer à la dernière version 6.5. Mais après déclassement SonarJava plugin(à partir de 4.11 4.12 pour), il a travaillé.
    Espérons qu'il saura vous aider.

    Merci Ben, qui va résoudre le problème, depuis mon SQ 6.4 ne viennent avec SonarJava4.9 et il a très bien fonctionné
    Oui je suis d'accord, mais après la mise à jour du plugin, j'ai affronté le problème. Mais après déclassement, il a travaillé.

    OriginalL'auteur Ben.Bean

  4. 0

    J'ai eu ce problème et je l'ai résolu de la manière suivante:

    Cette page mentionne au sujet d'une entrée qui était facultatif avant et est devenu obligatoire au cours de la dernière mise à jour (4.12). Il est dit que la sonar.java.binaries entrée dans le Jenkins projet de paramètres doivent être définis. Lorsqu'il est défini, même pour un mauvais dossier, il va corriger vos erreurs, ne laissant qu'un avertissement et votre portefeuille sera de nouveau en marche.

    Le réglage doit être ajouté à Jenkins -> "votre projet" -> Configuration -> Build -> Execute SonarQube Scanner -> Propriétés d'Analyse. Ajouter cette entrée et le point à vos binaires dossier.

    OriginalL'auteur Adrian vdBoom