Sonar permet de configurer, via une interface graphique, les niveaux de criticité des alertes remontées par PMD et Checkstyle. Ces niveaux peuvent ensuite (après quelques réglages) servir à influencer la santé des builds dans Jenkins - par exemple, l'utilisation de System.out.println provoquera un simple warning, alors que le lancement manuel d'un Throwable fera échouer le build.

Le problème, c'est que chaque outil dispose de ses propres niveaux de criticité, et il n'est pas toujours simple de déterminer leur correspondance d'un outil à l'autre : un réglage "minor" dans Sonar correspond-il à "info" ou "warning" dans PMD ? Et Jenkins le comprendra-t-il comme une alerte de type "low" ou "normal" ?

Je travaille actuellement sur l'industrialisation d'un gros projet "legacy" : je mets en place le build par Maven, l'intégration continue avec Jenkins, et la qualimétrie avec notamment PMD et Checkstyle, configurés via Sonar.

Le précédent billet expliquait comment j'avais réussi à placer le projet sous intégration continue avec Maven et Jenkins ; dans celui-ci, je parlerai de qualimétrie avec Sonar, PMD et Checkstyle.

Je travaille actuellement sur l'industrialisation d'un gros projet "legacy" : je mets en place le build par Maven, l'intégration continue avec Jenkins, et la qualimétrie avec notamment PMD et Checkstyle, configurés via Sonar.
Mais l'application ne respecte évidemment aucune des conventions de Maven - "multi-module" mais pas tout à fait, arborescence des sources différente, jars exotiques non identifiés...

Comme j'ai pas mal lutté pour faire marcher tout ça ensemble, je vous livre ici mon retour d'expérience et les quelques astuces que j'ai glanées ci et là.