Gregory Boissinot's Blog

Le blog déménage

2009-05-21T21:34:00.002+02:00

Devant la très grande pauvreté de l’interface d’administration de blogspot et la très grande difficulté de présenter des exemples de code sources, le blog passe sous Dotclear.

Un grand merci à Olivier Croisier qui m’a installé l’ensemble des outils Dotclear et réaliser le design du nouveau blog.

Désormais, voici donc l’adresse à suivre:
http://www.boissinot.net

Comparaison des serveurs d'intégration continue

2009-04-16T16:17:00.001+02:00

Si vous souhaitez comparer les différents serveurs d'intégration continue, voici deux liens utiles:

http://confluence.public.thoughtworks.org/display/CC/CI+Feature+Matrix

http://blog.chris-read.net/2008/09/22/continuous-integration-server-comparison-2008/

Relation entre les cycles de vie Maven et les goals des plugins Maven

2009-04-12T15:05:00.003+02:00

Pour de nombreuses personnes, la relation entre les goals des plugins et les cycles de vie Maven est obscure.
Le lien suivant présente une vidéo expliquant la relation entre ces deux notions
http://javidjamae.com/2009/04/09/screencast-maven-commands-and-lifecycles/

Changement du repository snapshot de Maven

2009-03-04T22:22:00.007+01:00

Précédemment, les artifacts snapshots de Maven se trouvaient à cette adresse: http://people.apache.org/repo/m2-snapshot-repository. Il est désormais "deprecated".

Désormais, toutes les nouvelles snapshots Maven seront déployées sur ce nouveau repository: http://repository.apache.org/snapshots.

Intégration de Maven dans Eclipse

2009-02-15T22:56:00.005+01:00

Devant la difficulté de l’intégration de Maven dans Eclipse et les très nombreuses questions sur ce domaine; Sonatype a décidé d’extraire son chapitre consacré à l’intégration du plugin m2eclipse du livre "Maven, The Definitive Guide". Ce chapitre donne naissance a un livre indépendant nommé "Developing with Eclipse and Maven".

Et voici l’url des trois livres proposés par Sonatype :
http://www.sonatype.com/documentation/books

Sortie de Sonar 1.6

2009-02-09T23:31:00.001+01:00

Il vient de sortir la version 1.6 de Sonar

Parmi les nouvelles fonctionnalités:
- possibilité de préciser des seuils
- gestion de profils de qualité et personnalisation par projet

Il va falloir l'essayer le plus rapidement possible.

Nouvelle version du plugin Gradle de Hudson

2009-02-08T20:05:00.003+01:00

La version 1.2 du plugin Gradle de Hudson est sortie ce week-end.
Plus d'informations sur ce billet.

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

2009-02-06T22:33:00.007+01:00

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

2009-02-05T23:33:00.013+01:00

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

2009-02-02T22:43:00.002+01:00

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

2009-01-24T21:44:00.007+01:00

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

2009-01-17T22:53:00.006+01:00

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

2009-01-17T18:17:00.006+01:00

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

2009-01-15T23:33:00.022+01:00

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).

Intégration continue et quelques problématiques

2009-01-15T09:30:00.013+01:00

Intervenant pour la mise en place de l'intégration continue dans un très grand groupe industriel; je fais face à des structures organisationnelles où l'intégration continue est perçue de façon très disparate.

Des organisations sont très motrices et demandeuses. En revanche, à l'inverse, je rencontre des personnes réticentes aux pratiques de l'intégration continue. Mon expérience m'amène à penser qu'il ne faut surtout pas imposer des mécanismes d'intégration mais apporter une démarche par la démonstration.

D'autres problématiques apparaissent comme : Quelle personne ou équipe doit réaliser la chaîne de build des applications et quelle personne ou équipe doit la maintenir? Trop souvent, les équipes considèrent l'intégration continue comme un mécanisme à mettre en place une seule fois et sera figé dans le marbre pour des années. Mon avis est que cela dépend des contextes. En dehors de la portée des applications Web de gestion, on constate que l'intégration continue est très souvent fortement couplée à l'architecture technique du projet. Dans de très nombreux contextes, cette architecture va évoluer (dans certains cas; elle sera complètement remaniée). La conséquence est un impact direct sur la chaîne de construction. C'est pourquoi, il est indispensable d'impliquer les équipes de développement dans les chaînes de construction des livrables.

N'hésitez à communiquer vos expériences!

Mise en oeuvre de Ivy2 dans Hudson

2009-01-08T23:12:00.028+01:00

Cette semaine a été livré le plugin Hudson pour le gestionnaire de dépendances Ivy 2.
L’objectif est de pouvoir déduire dans Hudson l’ordre d’exécution des jobs Hudson (1 job Hudson correspond à 1 projet Ivy) à partir des informations des dépendances fournies par Ivy.
Cette technique permet de renfoncer les bonnes pratiques qui consistent à avoir une chaîne d’intégration indépendante du scheduler (ici Hudson). Ainsi aucune configuration supplémentaire redondante n'est nécessaire.

Voici un exemple de mise en oeuvre.

Soient deux jobs Hudson nommée “job1” et “job2”

La première étape consiste à spécifier une configuration Ivy au niveau de Hudson

Configuration du premier projet
Spécifier une configuration de ivy (vous pouvez laisser celle par défaut si vous avez que 1 seul type de configuration)

Voici le contenu du fichier ivy-job1.xml:
<ivy-module version="1.0">
<info organisation="com.zenika.examples" module="job1"/>
</ivy-module>

Configuration du second projet

Voici le contenu du fichier ivy-job2.xml
<ivy-module version="1.0">
<info organisation="com.zenika.examples" module="job2"/>
<dependencies>
<dependency name="job1" rev="latest.integration" />
</dependencies>
</ivy-module>

Lancer au moins un build et le résultat upstream/downstream est le suivant

Le premier projet (job1) est une dépendance du second job (job2).
L’exécution du second job (job 2) est déclenchée après l’exécution du premier job ( job1).

Gradle en version 0.5.1

2009-01-07T23:12:00.006+01:00

Sortie de la version 0.5.1 de Gradle.
Cette version contient les corrections d'un ensemble de bugs (plus d'informations).

Nouvelle version du site MvnBrowser

2009-01-05T01:37:00.015+01:00

Juste après la publication du premier post sur les moteurs de recherche d'artefacts Maven, c'est une nouvelle version du site MvnBrowser qui vient juste d’être installée en ce début d’année. Cette nouvelle release fournit une amélioration du design et de la disposition des éléments. De plus, une nouvelle page est disponible, celle des licences transitives.

Il vous suffit d’aller a la section “pom report”, puis de saisir l’exemple suivant:

<dependencies>
<dependency>
   <groupId>org.jvnet.hudson.plugins</groupId>
   <artifactId>clearcase</artifactId>
   <version>0.8.1</version>
</dependency>
  <dependency>
   <groupId>junit</groupId>
   <artifactId>junit</artifactId>
   <version>4.4</version>
   <scope>test</scope>
</dependency>
<dependency>
   <groupId>org.springframework</groupId>
   <artifactId>spring-core</artifactId>
</dependency>
<dependency>
   <groupId>log4j</groupId>
   <artifactId>log4j</artifactId>
   <version>1.2.15</version>
</dependency>
</dependencies>

La première page du premier onglet montre l’ensemble des versions disponibles pour chaque dépendance en affichant un warning si nous n'utilisons pas de la dernière version de la librairie disponible.

Le deuxième onglet montre l’ensemble des librairies qui seront inclus dans le classpath.

Et le troisième onglet montre les licences des différents artefacts (et des artefacts récupérés par dépendance transitive).

Les moteurs de recherche d'artefacts Maven

2008-12-28T00:58:00.030+01:00

Voici un résumé des différents moyens pour rechercher les informations d'un artefact Maven.
Un artefact Maven est caractérisé par le triplet GAV (GroupId – ArtifactId – VersionId). Il faut connaître ces trois informations pour ajouter une dépendance dans votre descripteur Maven (pom.xml).

Par exemple, voici la déclaration d'une dépendance:
<dependency>
<groupId>V</groupId>
<artifactId>A</artifactId>
<<version>V</version>
</dependency>

Le repository central officiel de Maven est situé à l'adresse suivante http://repo1.maven.org/maven2/. De nombreux moteurs de recherche existent sur le marché afin d'obtenir les informations des artefacts dans les repository Maven. Chaque moteur a sa particularité de fonctionnement, et ainsi chacun ne renvoie pas des informations identiques pour une même demande d'artefact.

Un premier moteur de recherche connu est celui à l'adresse suivante : http://www.mvnrepository.com/. Celui-ci est déconseillé car il utilise un mirroir du repository central de Maven (http://mirrors.ibiblio.org/pub/mirrors/maven2/) au lieu d'utiliser directement le repository central. Au delà du délai d'attente de synchronisation, ce moteur a été souvent indisponible dans le passé.

Un autre moteur de recherche est celui l'adresse suivante : http://www.mvnindex.org. Il est très efficace et à jour dans ses méta données; je le recommande. De plus, couplé à son plugin Eclipse, ce moteur de recherche devient très pratique. Le seul reproche est qu'une recherche se limite uniquement au repository central.

Mais depuis peu, Sonatype a mis à disposition une instance du gestionnaire de repository Nexus à l'adresse http://repository.sonatype.org/index.html. Il s'agit d'une très bonne initiative que ne propose pas pour l'instant Archiva, le principal challenger de Nexus. L'avantage de cet instance publique est qu'elle agrège plusieurs repositories publiques dont le repository java.net, très utile pour rechercher les artefacts Hudson. Néanmoins, il existe un certain délai pour obtenir les dernières versions des artefacts. Prenons l'exemple de l'artefact "doxygen" de java.net qu'il ne trouve pas. Il ne trouve pas non plus par exemple, la dernière version du plugin clearcase de Hudson en version "0.8.1".

D'autres moteurs existent sur le marché comme l'ancien site "mavenreposearch" (http://maven.ozacc.com/). Il est également déconseillé à cause des données obsolètes renvoyées. Il existe également le moteur de recherche JavaRepo (http://javarepo.xoocode.org/). Partie d'une très bonne initiative puisqu'il peut servir également comme moteur de recherche pour Ivy, il semble ne plus être maintenu.

Et pour finir un nouveau moteur de recherche "mvnbrowser" à l'adresse http://www.mvnbrowser.com/index.html.
Celui-ci est très bien fait. Le premier avantage est la richesse des repositories agrégés. On peut apprécier également la qualité des informations du résultat de la recherche. A ce jour, je conseillerais d'utiliser ce dernier qui est le seule à renvoyer des informations correctes.

Packager Hudson avec ses plugins en Gradle

2008-12-28T00:27:00.020+01:00

Dans un précédent post, je spécifiais comment produire avec Maven, l'archive Web de Hudson incorporant un ensemble de plugins; voici son équivalent avec Gradle:

usePlugin('war')
group='org.jvnet.hudson'
version='1.266'
hudsonunpack= new File('build/hudson-unpack')
hudsonunpack.mkdirs()

boolean isPlugin(File dependency){
if ((dependency.getName()!=null) && (dependency.getName().endsWith(".hpi"))){
  return true;
}
return false
}

List plugins = [
'org.jvnet.hudson.plugins:doxygen:0.1@hpi',
'org.jvnet.hudson.plugins:gradle:1.1@hpi',
'org.jvnet.hudson.plugins:zentimestamp:1.0@hpi',
'org.jvnet.hudson.plugins:clearcase:0.8.1@hpi'
]

List core = [
'org.jvnet.hudson.main:hudson-war:'+version+'@war'
]

dependencies{
addMavenRepo('http://download.java.net/maven/2')
providedCompile core
providedRuntime plugins
}

createTask('hudson-unpack'){
dependencies.resolve("providedCompile").each{ depFile ->
  ant.unzip(src: depFile , dest:hudsonunpack)
}
}

createTask('copy-plugins'){
pluginsDir = new File(hudsonunpack,'WEB-INF/plugins')
pluginsDir.mkdirs()
dependencies.resolve("providedRuntime").each{ depFile ->
  if (isPlugin(depFile))
   ant.copy(file: depFile, todir: pluginsDir)
}
}

task('hudson-unpack').execute()
task('copy-plugins').execute()

archive_war{
baseName='hudson'
manifest.mainAttributes(
  "Main-Class": "Main",
  "Version": version)
fileSet(dir: hudsonunpack){
  exclude('**/HUDSON.RSA')
  exclude('**/HUDSON.SF')
}
}

J'avoue que l’utilisation de Gradle dans cet exemple ne permet pas de montrer sa pleine puissance et ses apports en comparaison de Maven. Néanmoins, la première remarque est l'aisance de la spécification des éléments pour la création de l'archive Web. La deuxième remarque concerne l'utilisation des tâches Ant (ant.copy et ant.unzip) pour réaliser l'équivalent des goals "copy" et "unpack" du plugin maven "maven-dependency-plugin". C'est un peu dommage, et pour l'instant sur ce point, Maven est supérieur. Mais une issue Jira (GRADLE-337) a été soumise sur le projet Gradle. N'hésiter pas à voter pour cette issue.

Sortie de Seam 2.1.1.GA

2008-12-25T17:04:00.006+01:00

Après les deux releases candidate 2.1.1.CR1 et 2.1.1.CR2, JBoss Seam a sortie pour Noël la release 2.1.1.GA. Cette nouvelle version contient les corrections de nombreuses anomalies qui persistaient.

Pour ceux qui utilisent Seam en version 1.x ou 2.0.x, n'hésiter pas à consulter les guides de migration comme le dernier.

Consulter le lien officiel de la sortie.

Packager Hudson avec ses plugins

2008-12-23T01:26:00.041+01:00

Depuis la version 1.259 de Hudson, il est possible de pré packager les plugins de Hudson dans l'archive Web (hudson.war).
Il suffit d'inclure les plugins (*.hpi) dans le répertoire « WEB-INF/plugins » de l'archive. Au lancement les plugins packagés seront déployés dans l'espace de travail de Hudson $HUDSON_HIOME/plugins.

L'exemple suivant montre la récupération d'une archive Hudson et d'un ensemble de plugins, puis son re-packaging avec Maven

<project xmlns="http://maven.apache.org/POM/4.0.0" xsi="http://www.w3.org/2001/XMLSchema-instance" schemalocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd"><project xmlns="http://maven.apache.org/POM/4.0.0" xsi="http://www.w3.org/2001/XMLSchema-instance" schemalocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
<modelversion>4.0.0</modelversion>

<groupid>org.jvnet.hudson.plugins</groupid>
<artifactid>hudson-war</artifactid>
<packaging>war</packaging>
<version>1.266</version>
<name>hudson-war</name>

<properties>
  <hudson.version>${project.version}</hudson.version>
  <hudson.unpack>${project.build.directory}/hudson-unpack</hudson.unpack>
</properties>

<build>
<plugins>
  <plugin>
   <groupid>org.apache.maven.plugins</groupid>
   <artifactid>maven-dependency-plugin</artifactid>
   <executions>
    <execution>
    <id>unpack-origin-archive</id>
    <phase>initialize</phase>
    <goals>
    <goal>unpack</goal>
    </goals>
    <configuration>
    <artifactitems>
    <artifactitem>
    <groupid>org.jvnet.hudson.main</groupid>
    <artifactid>hudson-war</artifactid>
    <version>${hudson.version}</version>
    <type>war</type>
   <overwrite>true</overwrite>
    <outputdirectory>${hudson.unpack}</outputdirectory>
    </artifactitem>
    </artifactitems>
    </configuration>
    </execution>

    <execution>
    <id>copy-plugins</id>
    <phase>initialize</phase>
    <goals>
    <goal>copy</goal>
    </goals>
    <configuration>
    <artifactitems>

    <artifactitem>
    <groupid>org.jvnet.hudson.plugins</groupid>
    <artifactid>clearcase</artifactid>
    <version>0.8.1</version>
    <type>hpi</type>
    <outputdirectory>${hudson.unpack}/WEB-INF/plugins</outputdirectory>
    </artifactitem>

    <artifactitem>
     <groupid>org.jvnet.hudson.plugins</groupid>
     <artifactid>doxygen</artifactid>
     <version>0.1</version>
     <type>hpi</type>
     <outputdirectory>${hudson.unpack}/WEB-INF/plugins</outputdirectory>
     </artifactitem>

    <artifactitem>
     <groupid>org.jvnet.hudson.plugins</groupid>
    <artifactid>zentimestamp</artifactid>
    <version>1.0</version>
    <type>hpi</type>
    <outputdirectory>${hudson.unpack}/WEB-INF/plugins</outputdirectory>
    </artifactitem>

    </artifactitems>
    </configuration>
    </execution>

    </executions>
    </plugin>

   <plugin>
    <groupid>org.apache.maven.plugins</groupid>
    <artifactid>maven-war-plugin</artifactid>
    <version>2.1-alpha-2</version>
    <configuration>
    <classifier>withplugins</classifier>
    <webresources>
    <resource>
    <directory>${hudson.unpack}</directory>
    <excludes>
    <exclude>META-INF/HUDSON.SF</exclude>
    <exclude>META-INF/HUDSON.RSA</exclude>
    </excludes>
    </resource>
    </webresources>
    <archive>
    <manifestfile>${hudson.unpack}/META-INF/MANIFEST.MF</manifestfile>
    </archive>
   </configuration>
   </plugin>

   </plugins>
</build>
</project>

Il vous suffira ensuite de lancer la commande mvn clean package pour obtenir la nouvelle archive Hudson hudson-war-1.266-withplugins.war avec les plugins inclus.

Retour sur le barcamp 2

2008-12-17T22:57:00.055+01:00

Voici le retour sur la session concernant l’intégration continue et les outils de build du barcamp deuxième edition organisé par OCTO mardi dernier. Cette session s’est déroulée en présence d’une dizaine de personnes ayant chacune un retour d’expérience a faire partager.

Partie sur les outils de build

Le premier sujet abordé a été « Maven au delà du poste de développement ». Un sujet délicat, qui revient souvent dans les équipes que je rencontre. Selon mon expérience, l'outil Maven doit être limité aux phases de compilation, de tests et de packaging. Il faut laisser le déploiement de ces artifacts aux scripts shell ou ksh souvent existant, et maintenus par une équipe spécifique dans les structures d’entreprises de taille importante. Maven doit donc être utilisé pour réaliser des fonctions de build uniquement. En revanche, il est important d’insister sur le fait que dans le cadre de développement JEE, l’archive Web produite doit être indépendante de l’environnement final. C’est au conteneur Web (ex :Tomcat) de contenir la configuration de l’environnement nécessaire comme par exemple la configuration de l’environnement de dev, de recette, de pre-prod et de prod. Et attention a l’utilisation abusive des profils Maven. Ces profils sont très utiles pour choisir le serveur de déploiement dans le cas d'une gestion de configuration des environnements des tests mais ne doit en aucun cas être utilisés pour réaliser un artifact de developement ou de recette en fonction de l’activation d’un profil de dev ou de recette (ex : -Penv=dev ou –Penv=rec). Utiliser cette technique pour ce cas d'utilisation est un abus de la puissance de Maven. En conclusion, il faut produire des artifacts génériques et classifier vos artifact par nature si besoin (sources, tests, …) et non pas par environnement.

L’autre point abordé a été l’utilisation de Maven dans les IDE. Pour Eclipse, l’utilisation de Maven est facilitée par l’intégration du plugin maven-eclipse-plugin (mvn eclipse:eclipse) ou par les plugins Eclipse Q4E ou m2eclipse. Un retour sur les lenteurs du plugin m2eclipse a été notifié. Cela renforce mon choix d’utiliser maven de manière complètement indépendante de l’utilisation des taches quotidiennes de développement au sein de l’IDE. A noter que rien ne vaut la gestion de Maven dans IDEA IntelliJ, qui depuis la version 7 permet une lecture directe des descripteurs Maven (pom.xml). Il a été également abordé la bonne intégration de Maven dans NetBeans. Mais la question que je me pose après coup : pourquoi utiliser NetBeans aujourd’hui pour les développements non Swing?

Il a été discuté ensuite de l’automatisation des tests d’IHM avec Selenium et de son intégration avec Maven. Selenium est un outil très populaire, qui s’impose aujourd’hui en entreprise. On peut affirmer que le concurrent Watij est en perte de vitesse. A noter que pour ceux qui exposent leur logique métier via REST, il est possible d’utiliser Selenium pour tester les flux http de retour dans le cas de XML. Concernant son intégration avec Maven, j’ai insisté qu’il s’agit de tests d’intégration et que Maven ne supporte pas très bien les tests d’intégration. La technique qu’il faut utiliser est de produire un module dédié aux tests d’intégration sur lequel la phase Maven des tests unitaires est skipée et que l'exécution des tests du projet est lié sur la phase Maven « integration-test ». Ensuite, il suffit simplement d’utiliser le plugin selenium server et le tour est joué.

Au delà de tout cela, j’ai essayé de montrer la lourdeur de Maven lorsqu’on sort des conventions en voulant scripter des produits non JEE comne des plugins RCP. Les conventions de Maven et le total manque de flexibilité me permettent d’affirmer qu’il est nécessaire de ne pas choisir Maven systématiquement comme builder pour vos applications Java. Dans ce cadre, il est plus intéressant de rester sur des scripts ANT ou de passer sur des scripts Gant ou Gradle. Gant est un langage de build au-dessus de Ant avec la syntaxe du langage Groovy. Couplé au gestionnaire de dépendances Ivy, il en fait un choix de premier ordre pour donner de la flexibilité à vos scripts de build. En revanche, si vous travaillez sur des projets plus conventionnés, ne pas hésiter a jeter un coup d’œil à Gradle qui est un outil de build comme Gant pour le langage de script en Groovy, mais avec en plus les conventions de Maven et un cycle de vie. Voici sur ce post, un exemple de gestion multi-projet avec Gradle.

D’autres outils on été cités en fin de session comme Raven, il s’agit d’un maven en Ruby. Le projet est en fin de vie. Desolé pour les fans de Ruby, mais Ruby n’a rien a envier comparé à Groovy ou Python (ou son petit frère pour Java : Jython).

A noter que pour ceux qui construisent des projets C/C++, l’outil très utilisé en entreprise est le builder Scons écrit en Python.

Les outils d’intégration continue

La deuxième partie de cette session a concernée plus spécifiquement les serveurs d’intégration continue. Sujet très ancien, tout le monde connaît le poste de Martin Fowler sur le sujet qui date de 2006, il s’agit néanmoins d’un sujet qui explose chez tous les clients ou j’interviens. En terme de choix d’outil, toutes les personnes dans la salle sont unaniment sur le fait que Hudson est le serveur d’intégration continue incontournable en ce moment. Cette affirmation est confirmée par le sondage fait à Devoxx comme signalé sur le blog du créateur de Hudosn: Kohsuke Kawaguchi.

Nous avons également discuté des livraisons très rapprochées de Hudson. Hudson produit une release très régulièrement de son core.
Comme j’en parle ici, il est important au niveau des ses clients de qualifier une version avant d’updater sa version de Hudson et il est bien sûr impossible d’utiliser systématiquement la dernière release de Hudson en production.

Il a été également abordé la gestion dans Hudson d’un projet multi-branche. L’autre approche des mécanismes multi-branche est l’utilisation d’une seule branche au niveau de son SCM et la pratique des pre-tested commit. Aujourd’hui, il s’agit de la seule fonctionnalité manquante au niveau Hudson, et qui pourrait nous faire basculer vers son principal challenger aujourd’hui TeamCty. Mais que les utilisateurs de Hudson se rassurent, cette fonctionnalité est en cours de développement et sera tout prochainement disponible.

Au-delà de ceci, quelques retours de plugins Hudson comme le CI game hudson plugin qui en conclusion ne sert à rien.

Le format court et la richesse du contenu ne m’a pas permit d’aborder de nombreux points qui me tenaient a cœur comme quelle personne ou équipe doit être en charge de faire évoluer le build continue? Et quelles sont les connaissances requises et nécessaires pour laisser une équipe être autonome avec une intégration continue?
Une prochaine fois sûrement.

En conclusion, une très bonne soirée dans des locaux impeccables, et le tout sur les Champs-Elysées.

Les composantes d’une intégration continue

2008-12-15T22:24:00.004+01:00

J’apprécie l’approche apportée par l’article de Meera Subbarao sur son blog sur les trois composantes de l’intégration continue :

Un gestionnaire de configuration comme Subvervsion ou Clearcase
Un moteur d’intégration continue comme Hudson
Un processus de build automatique s’appuyant par exemple sur Ant, Maven, Gant ou le nouvel outil de build Gradle

Gradle en version 0.5

2008-12-14T16:59:00.005+01:00

La version 0.5 de Gradle est sortie début décembre.
Parmi les nouveautés, on notera :
- Création de propriétés dynamiques
- Génération de bundle OSGI
- Déploiement dans un repository Maven
- Gestion améliorée de plusieurs niveaux de logging
- Le retour à un script de démarrage Windows (gradle.bat)
Cette dernière fonctionnalité est très importante, elle permet de prendre en compte clairement le code de retour de l'exécution d'un script de build Gradle. Une valeur correcte du code de retour de l'exécution d'un script est indispensable pour une possible intégration au sein d'un serveur d'intégration continue. A noter que l'intégration de Gradle dans Hudson à travers son plugin, prend déjà en compte cette fonctionnalité.