Archive for janvier 2009

Personnalisation du rapport Maven2 d’un projet

janvier 12, 2009

La commande « mvn site » permet de générer l’ensemble des rapports dans le répertoire target\site du projet. La page d’accueil est target\site\index.html. Rappelons que le contenu du répertoire target est généré par Maven. L’équipe de développement ne doit rien y placer manuellement. Son répertoire de travail est src. Enfin la commande mvn clean détruit le dossier target et son contenu. Cette commande reste utile lorsque Maven commence à avoir quelques problèmes.

Il est possible de configurer l’apparence du site. Je l’admet ce n’est pas fondamentalement important pour un petit projet, ou un petite structure. En plus, cela ajoute des fichiers de configuration. Un principe important de Maven est « convention over configuration ». Suivant ce principe, si une configuration n’est pas préciser,Maven utilise la convention par défaut. Ceci permet de réduire au maximum les fichiers de configuration au maximum. Notons qu’il s’agit un mouvement profond dans les outils de développement (comme Ruby on Rails)

Maintenant une grande organisation désire suivre une convention de présentation. C’est possible, il suffit d’ajouter un fichier site.xml dans le répertoire src/site. Il est possible que le dossier « site » n’existe pas encore. Ceci montre encore la puissance de Maven. Voici un exemple de fichier site.xml.


<project>
   <body>
      <links>
         <item name="Apache" href="http://www.apache.org/" />
         <item name="Maven 2" href="http://maven.apache.org/"/>
      </links>
      <menu ref="reports" />
   </body>
   <skin>
      <groupId>org.apache.maven.skins</groupId>
      <artifactId>maven-stylus-skin</artifactId>
      <version>1.0.1</version>
   </skin>
</project>

La partie link permet de créer des liens vers les sites sur l’entête des pages (en général en haut à droite). Le menu reports crée le menu concernant les différentes métriques et rapports (javadocs, rapport de test, couverture de code) définis dans le noeud reporting du fichier pom.xml. La partie skin du fichier site.xml permet de personnaliser l’apparence. Il existe sur les dépôts Maven 4 skin :
maven-classic-skin (version 1.0), maven-default-skin (version 1.0), maven-stylus-skin (versions 1.0 et 1.0.1) et maven-application-skin (version 1.0-SNAPSHOT).

Voici des impressions écran du même rapport avec ces 4 skins.

report-application-skin

report-classic-skin

report-default-skin

report-stylus-skin

Publicités

Utilisation de Maven2 en tant qu’outils de génération de rapports

janvier 1, 2009

Maven2 est un outils fascinant pour les personnes travaillant sur les projets Java. Il permet de gérer en premier les dépendances du projet. Mais il fournit d’autres fonctionnalités comme la génération de rapports (recherche de bugs, suivi de conventions de code, métriques), ceci en ajoutant quelques lignes de déclaration. En fait il prépare l’industrialisation des développements.

Les rapports sont générés suivant le cycle normal de Maven, par la commande : « mvn site:site ». Pour la génération de ces rapports, je conseille fortement d’utiliser Maven en ligne de commande et non le plugin m2 d’Eclipse (pour les utilisateurs de cet IDE). En effet, il existe trop de petits bugs dans ces plugins Maven pour Eclipse. Le rapport par défaut prévoit plusieurs informations de bon sens (about, project license, project team) qu’il est possible de renseigner dans le fichier pom.xml du projet.

Il est possible d’ajouter des plugins pour obtenir des rapport supplémentaires. Ceci se fait dans le noeud « reporting » du fichier pom.xml. Le plugin proviennent essentiellement du projet maven lui-même ou du projet mojo.codehaus.org. La déclaration est très simple en général, il suffit d’indiquer le groupId et l’artifactId du plugin. Les maniaques peuvent ajouter le numéro de version. Cette simplicité contraste avec le travail fait avec Ant.

Les premiers plugins que je propose d’utiliser sont en fait des plugins simples qui ne correspondent pas vraiment à des rapports classiques mais à des outils plus généraux. Le premier jxr (ou Xref) met simplement sous forme HTML le code source et celui des tests unitaires. Ce code source sera utilisé par d’autres plugins pour indiquer explicitement les lignes de code en problème. Ainsi, si un plugin (comme checkstyle) dit que telle ligne de code de telle classe ne respecte pas une convention de code, il est toujours plus agréable d’avoir un lien sur la ligne en question. La déclaration de ce plugin dans la partie reporting est :


<plugin>
   <groupId>org.apache.maven.plugins</groupId>
   <artifactId>maven-jxr-plugin</artifactId>
   <version>2.1</version>
</plugin>

Le second plugin est celui qui génère la javaDocs. Il est vrai que le format de la javaDocs est un peu vieillot mais il est largement utilisé dans les projets Java. Ensuite Eclipse permet de générer cette javaDocs, mais l’avantage de l’automatisation et l’intégration dans les rapports.


<plugin>
   <groupId>org.apache.maven.plugins</groupId>
   <artifactId>maven-javadoc-plugin</artifactId>
   <version>2.5</version>
</plugin>

Le troisième est également un plugin « simple ». Il s’agit de Surefire qui génère un rapport des tests unitaires dans le cadre des frameworks JUnit ou TestNG. L’écriture des tests unitaires est un point important pour un développement de qualité. Il faut cependant admettre qu’avoir le bon niveau de test n’est pas évident. Un détail important Maven ne semble pas exécuter les tests unitaires pour JUnit dans le même ordre que le plugin JUnit pour Eclipse. En soit, c’est une bonne chose, car les tests unitaires doivent être indépendants les uns des autres.


<plugin>
   <groupId>org.apache.maven.plugins</groupId>
   <artifactId>maven-surefire-report-plugin</artifactId>
   <version>2.4.3</version>
</plugin>

Le quatrième plugin que je propose analyse le code, de manière simple. Il s’agit de taglist. Il va repérer les tags //TODO ou @todo laissés dans le code. Il est possible d’ajouter d’autres tags (par exemple @deprecated ou //FIXME) en configurant le plugin. Un conseil en passant, les //TODO sont généralement créés par les générateurs de code. Je ne les efface pas mais je remplace par des //DONE. Dans l’exemple suivant je configure explicitement 4 tags


<plugin>
   <groupId>org.codehaus.mojo</groupId>
   <artifactId>taglist-maven-plugin</artifactId>
   <version>2.3</version>
   <configuration>
      <tags>
         <tag>TODO</tag>
         <tag>FIXME</tag>
         <tag>@todo</tag>
         <tag>@deprecated</tag>
      </tags>
   </configuration>
</plugin>

Il existe d’autres plugins comme checkstyle, cobertura, pmd, JDepend. A vos de les étudier et de voir ce qui convient à votre projet.