[Sonar] Mise-à-jour de l'article sur Sonar

[romaintaz]

Bonjour à toutes et à tous,

Mon article sur Sonar a été publié il y a 11 mois tout juste, lorsque la version 1.4 était la dernière version existante.
Aujourd'hui, alors que la version 1.10 est (quasiment) sortie, je viens de mettre à jour cet article !

Il est visible ici.

Vos commentaires, vos réactions sont les bienvenus !

[gboissinot]

Très bon article!

Aujourd'hui Sonar s'ouvre à d'autres langages que Java comme le PHP. Il y a également des plugins pour le C/C++ en préparation. De même, il est tout à fait possible d'avoir un jour des plugins pour le langage Ada. C’est pourquoi, il pourrait être intéressant de rajouter une partie sur cela dans une prochaine version.

Qu'en penses-tu?

PS : Si tu as besoin d'aide, je pourrais te donner un coup de main.

[romaintaz]

Merci pour ton retour,

Pour le moment, Sonar ne gère que le Java (et le PL/SQL), même si effectivement la gestion du PHP est en cours de développement (à moins que ce ne soit sorti, mais j'en doute).

Je ferais sans doute un update de l'article en fin d'année, où j'incluerais ces informations !

[gboissinot]

Pour info, voici les pages Wiki pour le support de PHP et de C/C++.

Pour le PHP
http://docs.codehaus.org/display/SONAR/Sonar+PHP+Plugin

Pour le C/C++
http://docs.codehaus.org/display/SONAR/CPP+plugin

Effectivement, le plugin PHP n'est pas encore sorti.

[*alexandre*]

Excellent article une mine d'informations très utile !

[Baptiste Wicht]

Merci pour cet excellent article

Je viens d'installer Sonar en suivant ton article et ça c'est très bien passé.

Je n'ai pas encore tout testé, loin s'en faut, mais c'est tout de même dommage d'être obligé de passer par Maven. Personnellement, j'utilise toujours Ant pour mes buils et je n'ai pas envie d'apprendre Maven. J'ai mis un bon moment à configurer un pom.xml qui marche correctement pour mon projet.

J'avais juste une question avec ça, si je veux que Sonar calcule la couverture de codes, je dois éxécuter les tests unitaires avec Maven et il detéctera ou il faut faire autre chose ?

[gboissinot]

Sonar utilise Maven 2 sous le capot. Il en a besoin pour analyser les sources et injecter les résultats de l'exécution des métriques dans sa base de données. C'est pourquoi, pour utiliser Sonar, on doit installer et configurer Maven.

Néanmoins, il est toujours possible d'utiliser un autre outil de build que Maven comme builder de son projet. En effet, nombreux sont les projets n'utilisant pas Maven pour différentes raison (connaissance insuffisante, non adapté au contexte projet, trop limité, ...).

Dans ce cas, tu dois utiliser le mode "Sonar light".

Il te faut créer un descripteur Maven (pom.xml) et invoquer Sonar avec ce descripteur Maven (mvn sonar:sonar) avec un ensemble de propriétés systèmes spécifiant l'emplacement des rapports de métriques (résultats des tests, couverture de code, ...) générés par le builder de ton projet (Ant, Gradle, ...).
Parmis ces propriétés, tu as notamment la propriété "sonar.dynamicAnalysis" à "reuseReports" indiquant à Sonar de ne jouer que le rôle d'un collecteur de données.

Tu trouveras bien sûr plus d'informations sur la page officielle du Wiki de Sonar
http://docs.codehaus.org/display/SON...+Java+Projects

Ainsi pour répondre précisément à ta question, tu peux continuer à utiliser Ant pour exécuter tes tests et produire les rapports du résultat des tests et de de la couverture de code. Ton apprentissage à Maven se limitera à la création du pom.xml template.

De plus, si tu es sous intégration continue et tu utilises Hudson, tu peux déléguer la création du descripteur Maven au plugin Sonar de Hudson.
http://wiki.hudson-ci.org/display/HUDSON/Sonar+plugin

Mais, c'est vrai qu'il faudra toujours installer et configurer Maven pour pouvoir utiliser Sonar. Néanmoins, dans cette situation, Maven sera uniquement un outil d'infrastructure et il ne sera pas un outil de build pour le développeur.

Néanmoins, il est tout à fait légitime de se poser la question, pourquoi avoir besoin d'installer la très lourde infrastructure Maven quand je n'ai pas déjà Maven. Cette problématique deviendra d'autant plus importante dans l'avenir quand Sonar supportera officiellement d'autres langages comme le C/C++ et PHP ou même ADA. En effet, Maven n'est pas vraiment un outil adapté pour ces derniers langages.
Et il est tout à fait légitime d'admettre que les intégrateurs de ces plateformes ne souhaitent pas mettre en place Maven pour utiliser Sonar. Le risque à terme serait la non possibilité d'utiliser Sonar. Et c'est dommage!

A mon avis, cette problématique n'est pas une priorité à court terme pour l'équipe Sonar, devant la popularité et le très fort déploiement aujourd'hui de Maven sur les projets. Mais à terme, il sera sans aucun doute nécessaire d'avoir un mode d'installation et d'utilisation plus simple de Sonar, c'est à dire sans Maven.

Selon moi, je vois bien le remplacement en interne de Maven par Gradle.
Les conventions fournis par Gradle et ses plugins permettraient à Sonar de pouvoir invoquer et collecter les résultats des métriques comme il le fait avec Maven aujourd'hui. Ensuite, pour les dépendances vers les plugins Sonar et les dépendances vers les librairies métiers (log4j.jar, checkstyle.jar, ...), Sonar pourrait utiliser Ivy (natif dans Gradle) permettant d'exploiter les librairies avec un resolver local, c'est à dire embeded dans un répertoire du file système mis en place au moment de l'installation de Sonar.

[Baptiste Wicht]

Merci, mais ça j'avais déjà compris, désolé , mais tu as eu le mérite de clarifier le tout

C'est effectivement ce que j'avais avec Sonar Light, mais même avec ça, pour configurer toutes les dépendances de mon projet, je me suis bien emmerdé pour moi qui connait très peu Maven...

Par contre, j'aimerais bien éviter de dépendre du build Ant pour la couverture de code. Donc, pour que Sonar détecte mes tests et effectue les calculs de couverture de code, il faut que mes tests soient éxécutés depuis Maven, c'est bien ça ?

[gboissinot]

En fait, ton besoin est peu habituel.
Si j’ai bien compris, tu vas utiliser au sein de ton projet à la fois le builder Ant et le builder Maven.
Est-ce qu’il y a une raison bien particulière de ce choix ou de cette contrainte?

De plus, ton outil de couverture de code (comme Cobertura) va également relancer les tests pour calculer la couverture de code et donc tes tests seront lancés aussi par Maven, donc…

Ou alors, tu veux instrumenter tes classes par Maven, lancer tes tests avec Ant et exécuter l’action de génération du rapport de couverture de code (au format XML) avec Maven?
Je pense que cela est un peu tordu.

Bref, excuse-moi mais j’ai du mal à comprendre ton besoin.

Mais sinon, si tu veux mixer des actions Ant et Maven avec Sonar, oui c’est possible.

Donc si tu es en full Ant, tu crée un pom template avec par exemples les propriétés suivantes

Code :

1
2
3
4
5
6
  <properties>
    <sonar.dynamicAnalysis>reuseReports</sonar.dynamicAnalysis>
    <sonar.surefire.reportsPath>bin/surefire-reports</sonar.surefire.reportsPath>
    <sonar.cobertura.reportPath>bin/coverage/coverage.xml</sonar.cobertura.reportPath>
  </properties>

Et tu lances au niveau du projet, la ligne de commande suivante

Code :

1
2
mvn sonar:sonar

Si tes tests sont lancés avec Ant et la couverture de code est gérée avec Maven (instrumentation, test et génération du rapport), tu auras par exemple les informations suivantes

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
  <properties>
    <sonar.dynamicAnalysis>reuseReports</sonar.dynamicAnalysis>
    <sonar.surefire.reportsPath>bin/surefire-reports</sonar.surefire.reportsPath>
    <sonar.cobertura.reportPath>target/site/cobertura/coverage.xml</sonar.cobertura.reportPath>
  </properties>

  <build>
    <plugins>
      <plugin>
        <groupId>org.codehaus.mojo</groupId>
        <artifactId>cobertura-maven-plugin</artifactId>
        <configuration>
	  <formats><format>xml</format></formats>
        </configuration>
      </plugin>
    </plugins>
  </build>

Et tu lances au niveau du projet, la ligne de commande suivante

Code :

1
2
mvn cobertura:cobertura sonar:sonar

En espérant que cela t’aide.

[*alexandre*]

Envoyé par Baptiste Wicht

Merci pour cet excellent article

Je viens d'installer Sonar en suivant ton article et ça c'est très bien passé.

Je n'ai pas encore tout testé, loin s'en faut, mais c'est tout de même dommage d'être obligé de passer par Maven. Personnellement, j'utilise toujours Ant pour mes buils et je n'ai pas envie d'apprendre Maven. J'ai mis un bon moment à configurer un pom.xml qui marche correctement pour mon projet.

J'avais juste une question avec ça, si je veux que Sonar calcule la couverture de codes, je dois éxécuter les tests unitaires avec Maven et il detéctera ou il faut faire autre chose ?

C'est pas une tâche trop complexe de passer à maven dès lors que tu as déjà configurer un projet avec ant (il faut juste se souvenir de la version des libs)

D'ailleurs ou tu as fait ton apprentissage le passage à maven est déjà prévu et plein d'autres choses

[Baptiste Wicht]

C'est vrai que ça peut paraître compliqué.

En fait, j'utilise TeamCity pour calculer la couverture de code, mais je ne suis pas trop satisfait, parce qu'avec ça les fichiers jar sont instrumentés avec emma et nécessite emma.jar à l'éxécution, c'est donc pour ça que j'aimerais découpler la partie build de la partie tests et analyse.

Mais en réfléchissant et en lisant tes explications, je me rends compte que tout ce que j'ai à faire, c'est supprimmer le mode light de sonar et tout est analysé correctement

Merci beaucoup pour tes explications

[*alexandre*]

Envoyé par Baptiste Wicht

C'est vrai que ça peut paraître compliqué.

En fait, j'utilise TeamCity pour calculer la couverture de code, mais je ne suis pas trop satisfait, parce qu'avec ça les fichiers jar sont instrumentés avec emma et nécessite emma.jar à l'éxécution, c'est donc pour ça que j'aimerais découpler la partie build de la partie tests et analyse.

Mais en réfléchissant et en lisant tes explications, je me rends compte que tout ce que j'ai à faire, c'est supprimmer le mode light de sonar et tout est analysé correctement

Merci beaucoup pour tes explications

Il n'y aucun problème au fait d'intégrer une librairie si celle-ci ne créer pas de dépendance avec ton serveur d'application et se retrouverait en conflit avec des librairies livrées avec ce dit serveur. Et même si ca arriverait tu pourrais toujours définir au niveau de ton livrable ta préférence pour une librairie livrée avec ton application.

[Baptiste Wicht]

romaintaz, tu sais quand est-ce que les modules seront compatibles avec cette nouvelle version ?

[romaintaz]

Envoyé par Baptiste Wicht

romaintaz, tu sais quand est-ce que les modules seront compatibles avec cette nouvelle version ?

Hello Baptiste,

De quels modules parles-tu exactement ? Des plugins ?

[Baptiste Wicht]

Envoyé par romaintaz

Hello Baptiste,

De quels modules parles-tu exactement ? Des plugins ?

Erf, oui, je voulais dire plugins

[romaintaz]

De quels plugins parles-tu ? Ceux déjà disponibles (sur cette page) ?
Dans ce cas, il faut attendre que chaque développeur fasse la mise à jour de son plugin pour le rendre compatible avec Sonar 1.10 (je ne sais pas si on peut installer sans trop de soucis un plugin prévu pour la 1.9 sur la 1.10).

[Baptiste Wicht]

Envoyé par romaintaz

De quels plugins parles-tu ? Ceux déjà disponibles (sur cette page) ?
Dans ce cas, il faut attendre que chaque développeur fasse la mise à jour de son plugin pour le rendre compatible avec Sonar 1.10 (je ne sais pas si on peut installer sans trop de soucis un plugin prévu pour la 1.9 sur la 1.10).

Ben, à priori non ^^

J'ai testé MetricsAnalytics sans succès, l'application ne démarrait pas du tout, pareil pour TechnicalDebt et TagList.

Je vais attendre, merci

[romaintaz]

C'est bizarre, Taglist et TechnicalDebt sont utilisés sur Nemo qui tourne sur un Sonar 1.10 (RC4 pour être précis).

Bon, peut-être que l'équipe de développement de Sonar a installé des versions non encore définitives de ces plugins...

[Baptiste Wicht]

Envoyé par romaintaz

C'est bizarre, Taglist et TechnicalDebt sont utilisés sur Nemo qui tourne sur un Sonar 1.10 (RC4 pour être précis).

Bon, peut-être que l'équipe de développement de Sonar a installé des versions non encore définitives de ces plugins...

Faudrait que j'essaie à nouveau, mais j'avais pas pu faire démarrer sonar avec ces deux plugins

[romaintaz]

Le plugin TechnicalDebt est en cours de vote pour release pour sa version 0.3, compatible avec Sonar 1.10...
Plus longtemps à attendre donc