Résultat d’une étude sur les outils d’intégration continue

Voici le résultat d’une étude intéressante sur les différents serveurs de CI. On y apprend notamment que Hudson et CruiseControl sont les deux principaux outils du marché.
Pour le moment, c’est CruiseControl qui est le plus utilisé. Pour les projets déjà sous CI, ils migrent peu à peu vers Hudson ; et pour les projets démarrant des processus d’intégration continue, ils choissent directement Hudson. Il est certain que ce dernier scheduler est très avancé grâce notamment à sa très grande quantité de plugins.

Faire cohabiter le site Maven et Sonar

Maven est un système de build complet. Il fournit le cycle de vie « site » pour générer la documentation du projet. Cette documentation contient des informations générales sur le projet comme le triplet GAV(GroupId, ArtifactId,Version), les dépendances, les licences, ... ; ainsi que le résultat de l’exécution des métriques. Le principal inconvénient est d’avoir une documentation purement statique. Par exemple, la documentation contient uniquement une page de résultat par métrique (Checkstyle, PMD, Emma, ...). Ces métriques ne sont donc pas agrégées. De plus, il n’est plus à démontrer que c’est la partie de Maven qui est la moins aboutie du produit en terme de fiabilité.

Désormais, c’est l’outil Sonar qui est très utilisé pour le suivi de la qualité de code des projets informatiques développés en Java. Il s’agit d’une application Web avec une base de donnée, fournissant une méthode complète pour suivre l’évolution de la qualité de code pendant les phases de développement.

Le billet du blog de Sonar résume une fois pour toute comment cohabiter le site Maven et l’outil Sonar.

En conclusion, il faut utiliser le site Maven uniquement pour vos informations générales, puis fournir un lien sur l’url Web de l’instance Sonar.

Dashboard Hudson des projets Apache

Pour ceux qui ne connaissent pas encore le dashboard Hudson de l’ensemble des projets Apache, voici l’adresse
http://hudson.zones.apache.org/hudson/

Gradle et gestion d'un proxy

Dans vos projets Gradle, si vous utilisez des repository Maven distants pour récupérer vos artefacts et que vous êtes derière un proxy, vous devez spécifier les informations du proxy dans un fichier "gradle.properties" avec le contenu suivant:

systemProp.http.proxyHost=<proxyHost>
systemProp.http.proxyPort=<proxyPort>
systemProp.http.proxyUser=<proxyUser>
systemProp.http.proxyPassword=<proxyPassord>

Ce fichier est situé dans le même répertoire que le descripteur Gradle (build.gradle)

Et la déclaration de vos dépendances sera par exemple

dependencies{
  addMavenRepo('http://download.java.net/maven/2')
  providedCompile 'org.jvnet.hudson.main:hudson-war:'+version+'@war'
 }

Dans une infrastructure multi-utilisateur, il est préférable d'utiliser un gestionnaire de repository Maven comme Archiva ou Nexus.
Vous trouverez un exemple d'une configuration de Archiva avec un projet Gradle sur ce billet.

Un bon billet sur les meilleures pratiques de l'intégration continue

Je vous invite à consulter le billet du blog de Sonatype sur les meilleures pratiques de l'intégration continue: le billet

On y apprend notamment, que si on active la propriété système "-Dsurefire.useFile=false" d'un build Maven, les résultats des tests et les explications des tests en erreur sont directement affichés dans la console. Cela est très utile quand la chaîne de build Maven est intégrée au sein d'un scheduler comme Hudson.

Hudson et le cloud computing

Depuis la version 1.271; Hudson commence à se doter d'un système de cloud computing. C'est une nouvelle vision, Hudson va proposer des mécanismes d'intelligence qui détectent les surcharges. L'objectif est par exemple de fournir une très bonne gestion dynamique des builds en cluster.

Suivez la discussion sur le sujet : ici

Plusieurs spécifications JEE6 sont sorties

Apres dix ans d’existence, JEE arrive à sa sixième version, très attendue.
Les 3 mots d’ordres de cette nouvelle version sont :
- plus riche (plus de spécifications et un spectre plus large)
- plus simple (une orientation POJO, moins de XML; y compris pour la DMZ Web)
- plus léger (EJB Lite, les profiles, et le « pruning », comprenez un fort depracated)
Les spécifications des Servlet 3.0, JSF 2.0 de JEE6 sont sorties aujourd’hui.

Servlet 3.0 (JSR 315)
Cette spécification est la plus attendue des différentes spécifications de JEE6.
On pourra spécifier nos composants de présentation JEE avec les annotations comme @WebServlet, @ServletFilter, @WebServletContextListener. Ces annotions permettront de se passer du descripteur de déploiement (web.xml). Au delà de son optionalité, on pourra le modulariser avec la notion de fragments.

JSF 2.0 (JSR 314)
Toujours dans une politique de simplification, le descripteur JSF faces-config.xml sera optionnel.
On pourra faire cela @ManageBean(name="operateur",scope="session") puis @ManageProperty(value="...")
Et enfin, cela sera basé complètement sur Facelets, supprimant définitivement l'utilisation des JSP pour une application JSF.

A suivre également les spécifications JCA(JSR322) et SDO(JSR235).