Nous avons vu précédemment comment installer Sonar et le Java Runner. Celui-ci nous permet d’effectuer des analyses sans passer par des outils tels que Maven ou Ant.

Dans ce post, nous allons voir comment effectuer une première analyse sur du code Mainframe-Cobol.

Rappelons que:

• Le fichier sonar-runner.properties est dédié à la connexion à Sonar et notre base de données.
• Le fichier sonar-runner.bat nous permet de lancer une analyse.

Environnement d’analyse

Lorsque vous installez un serveur d’analyse de code, il est important de bien différencier les différents espaces en fonction de leur objet :

• L’espace consacré aux différents logiciels et leurs différentes versions : Oracle, Java, Tomcat, Sonar, etc.
• L’espace dédié à la livraison et l’installation du code source à analyser.
• L’espace dédié à l’implémentation des analyses : configuration, backups, customisations, création de rapports, extraction de données, documentation de vos analyses (utile lorsque celles-ci se multiplient ou qu’on doit revenir sur une analyse ancienne ou que notre serveur d’analyse est utilisé par différents opérateurs), etc.

Sonar nous permet de spécifier cet espace dans le sonar-runner.bat, avec la variable PROJECT_HOME. Nous allons donc rechercher dans ce fichier la ligne suivante :

set PROJECT_HOME=%CD%

et la modifier de façon à indiquer un sous-répertoire \Projets dans lequel nous placerons les fichiers de configuration de nos analyses. Dans la réalité, je ne localiserais pas cet espace sous le répertoire du Java Runner, c’est uniquement à titre de démonstration.

J’ai modifié le fichier sonar-runner.bat pour insérer les 3 lignes suivantes :

• Afficher le répertoire du Java Runner SONAR_RUNNER_HOME:

echo « SONAR_RUNNER_HOME = %SONAR_RUNNER_HOME% »

• Spécifier le répertoire d’analyse PROJECT_HOME dans un dossier \Projets sous le répertoire précédent, et l’afficher :

set PROJECT_HOME=%SONAR_RUNNER_HOME%\Projects
echo « PROJECT_HOME = %PROJECT_HOME% »

Configuration de notre première analyse

Afin d’effectuer une analyse, le Java Runner se base sur le fichier sonar-project.properties situé dans notre environnement d’analyse. Notre objectif est d’analyser quelques programmes Cobol localisés dans un répertoire C:\SRC\Mainframe.

Sans entrer dans le détail des paramètres pour une analyse de code mainframe, nous allons créer notre fichier sonar-project.properties avec les attributs suivants :

• Tout d’abord, les données obligatoires : un nom / une clé pour cette application, objet de notre première analyse, ainsi qu’un numéro de version :

# required metadata
sonar.projectKey=CBL_1
sonar.projectName=Cobol 1st Analysis
sonar.projectVersion=1.0

• Et bien sûr, l’emplacement des fichiers à analyser :

sources=C:/SRC/Mainframe

• Dernier paramètre : le langage de programmation qui décidera du parser Sonar pour analyser cette application :

#The value of the property must be the key of the language.
sonar.language=cobol

Exécution de notre première analyse

Dans une fenêtre de commande DOS, nous lançons le fichier sonar-runner.bat :

• Nous voyons bien s’afficher les 2 variables désignant le répertoire du Java Runner et de notre espace d’analyse : Avec le répertoire localisant les fichiers source :

• Et toute erreur d’analyse éventuellement rencontrée (ici, une chaîne de caractères incorrecte) :
• Heureusement, une erreur de syntaxe dans le code Cobol ne va pas arrêter Sonar, et notre analyse se termine bientôt avec le message :

Nous pouvons maintenant consulter le portail Sonar et voir s’afficher les résultats de notre première analyse :

Nous avons donc pu mener à bien notre première analyse de la façon la plus simple qui soit, en configurant les quelques paramètres requis dans le fichier sonar-project.properties, sans nécessité de gérer des fichiers xml de Maven à la syntaxe parfois longue et complexe.

Néanmoins, la méthode décrite ici présente deux inconvénients :

• Le Java Runner travaille uniquement avec le fichier sonar-project.properties. Renommez celui-ci dans votre espace d’analyse et le Java Runner ne pourra fonctionner correctement. Il faut donc modifier ce fichier chaque fois que l’on effectuera une nouvelle analyse différente de la précédente.
• Consulter les erreurs dans notre fenêtre de commande DOS n’est pas des plus convivial, surtout pour des analyses assez longues et/ou rencontrant beaucoup d’erreurs.

Nous allons voir dans notre prochain post comment remédier à cela, grâce à notre ami Jenkins.

Cette publication est également disponible en Leer este articulo en castellano : liste des langues séparées par une virgule, Read that post in english : dernière langue.