Blog Xebia France » Maven

Troisième édition de notre atelier : Continuous Deployment sur Tomcat avec Jenkins, Rundeck et DeployIt

Xebia France — Wed, 21 Dec 2011 07:00:54 +0000

Répondant à la demande, le 31 janvier nous rééditerons la soirée des 13 et 20 octobre derniers !

La saison est au Continuous Delivery ! Venez découvrir comment automatiser le déploiement d’une application java web typique sur des serveurs Tomcat via une usine GitHub/Jenkins/Nexus.

Nous verrons plusieurs techniques de déploiement, de la plus simple à la plus sophistiquée :

déploiement sur Tomcat avec des commandes shell lancées par Jenkins au lieu de les lancer à la main ;
utilisation du tomcat-maven-plugin avec les conseils d’Olivier Lamy, lead developer du plugin et committer Tomcat ;
homogénéisation des déploiements du dev à la prod avec Jenkins associé à Rundeck pour gérer des commandes shell. Vincent Behar, committer Jenkins et ‘owner’ du jenkins-rundeck-plugin nous présentera cet outil Open Source en vogue chez les OPS ;
DeployIt : l’outil intégré d’automatisation des déploiements made in Xebia.

Pour avoir plus de détails sur le déroulement de l’atelier et pour vous inscrire, nous vous invitons à utiliser la page dédiée sur Eventbrite.

Retour Atelier Continuous Delivery – Partie 2 – Déploiement continu avec Jenkins Remote SSH Plugin

Xavier Bucchiotty — Fri, 02 Dec 2011 14:30:14 +0000

Pour déployer une application sur un serveur Tomcat distant, nous avons vu précédemment comment utiliser Apache Tomcat Maven Plugin. Nous pouvons aussi utiliser un script. Cette solution plus élaborée est certainement plus proche des solutions d’exploitation existantes aujourd’hui dans nos entreprises.

Dans l’esprit DevOps, il faut avoir un mode de déploiement le plus tôt possible identique à celui de la production. L’approche par script convient ainsi à un maximum d’environnements possibles (du test jusqu’à la production).
Pour ce faire, le script sera placé sur le serveur distant et exécuté à distance.

Le but de cet article est de vous proposer une solution pour déployer une application web sur un serveur Tomcat distant à chaque commit sur votre repository. Pour cela, nous allons utiliser le plugin Remote SSH pour Jenkins.

Prérequis

Lors de l’atelier, les différents outils étaient fournis sur des machines virtuelles Linux sur Amazon EC2. Si vous souhaitez refaire les manipulations sur votre poste, vous aurez besoin d’installer :

un JDK
Apache Maven
Nexus
Jenkins
Apache Tomcat 6
le script de déploiement créé pour l’atelier, disponible ici : tomcat-deploy-petclinic.

Il vous faudra donc une machine distante avec un serveur SSH si vous souhaitez réaliser cet exemple.

Téléchargement du projet d’exemple

Nous avons mis à disposition un projet d’exemple xebia-petclinic-lite sous GitHub. Pour tester cet article, vous pouvez cloner ce projet. Nous avons déjà décrit cette partie dans notre précédent article.

git clone https://github.com/xebia-france-training/xebia-petclinic-lite.git

Vous devez avoir un serveur Nexus installé en local. Une fois installé, vous devez changer dans le pom.xml les URLs des repositories avec vos valeurs (le serveur Nexus des Xebia Tech Events n’est actif que pendant les ateliers).


 
  xebia-tech-event-nexus-releases
  Xebia Tech Event Nexus Releases
  http://votreNexus/content/repositories/releases
 
 
  xebia-tech-event-nexus-snapshots
  Xebia Tech Event Nexus Snapshots
  http://votreNexus/content/repositories/snapshots

Ensuite, un « mvn deploy » permettra d’avoir un projet fonctionnel déployé dans votre repository.

Création du script

Le script shell que nous allons créer doit assurer les fonctions suivantes :

Arrêter Tomcat,
Supprimer le war et les dossiers de l’application dans webapps et temp,
Télécharger une version de l’application depuis Nexus,
Démarrer Tomcat,
Effectuer un test de connexion HTTP à la page principale de l’application pour vérifier le bon démarrage de l’application déployée.

Pour le téléchargement du war, nous faisons appel à l’API REST du serveur Nexus. Nous allons utiliser le service /artifact/maven/content, dont voici les paramètres :

g : Group id de l’artéfact (Obligatoire).
a : Artifact id de l’artéfact (Obligatoire).
v : Version de l’artéfact (Obligatoire) Supporte les mots-clés comme « LATEST », « RELEASE » et les version SNAPSHOT ou non (« 1.0-SNAPSHOT », « 1.2.3′ …).
r : Identifiant du repository Nexus qui contient l’artéfact (Obligatoire). Attention, par défaut, les artéfacts versionnés et les snapshots ne sont pas stockés dans le même repository. Donc pensez à mettre le bon identifiant de repository ici « releases » ou « snapshots » (rechercher des versions SNAPSHOT dans le repository RELEASES ne va pas être simple !). Petite astuce, vous pouvez aller voir dans votre settings.xml de Maven pour connaitre les repositories (normalement, seulement présent sur le serveur d’intégration continue).
p : Type de packaging de l’artéfact (Optionnel, par défaut il vaut .jar, donc pour un .war, il faut bien penser à le spécifier).
c : Qualificatif de l’artifact (Optionnel, voir la notion d’identifier dans MAVEN).
e : Extension de l’artéfact (Optionnel) A VOIR

Ainsi, télécharger la dernière snapshot d’un artefact peut se faire grâce à une simple commande CURL sous Unix, dont voici un exemple :

curl "http://nexus.xebia-tech-event.info:8081/nexus/service/local/artifact/maven/content?g=fr.xebia.demo.petclinict&a=xebia-petclinic-lite&r=snapshots&v=LATESTS&e=war" \
   --silent \
   --show-error  \
   --output "/opt/tomcat/apache-tomcat-6/webapps/xebia-petclinic-lite.war"

Comme dit plus haut, le serveur Nexus du Xebia Tech Event est démarré uniquement pendant les ateliers, inutile donc d’essayer cette URL depuis chez vous !

Pour vérifier le bon démarrage de Tomcat, on peut de nouveau utiliser la commande CURL pour vérifier si l’application est bien déployée. En voici un exemple :

curl --connect-timeout 10 --retry 10 --silent --show-error -w "%{http_code}" -o /dev/null http://localhost:8080/xebia-petclinic-lite

Vous pouvez retrouver le script complet qui nous a servi pendant l’atelier sur tomcat-deploy-petclinic. Seules quelques adaptations seront nécessaires pour utiliser ce script sur vos environnements de production (changement de groupId, d’URL de repository Nexus, etc).

Le plugin Remote SSH pour Jenkins

Notre script est maintenant prêt. Il ne vous reste plus qu’à le transférer vers votre machine distante (par SCP ou FTP, comme bon vous semble). Une fois sur le serveur, vous pouvez le lancer « à la main » pour vérifier qu’il fonctionne.

Dans notre exemple, nous nous authentifions sur les serveurs grâce à des clés privées, mais le reste de l’exercice peut aussi se faire avec un login et un mot de passe si vous le souhaitez.

Le Jenkins Remote SSH Plugin permet de se connecter à un serveur distant et d’y exécuter une série de lignes de commande. Un des avantages majeurs de la solution est qu’elle n’est pas intrusive. En effet, il n’y a pas d’agent spécifique à installer sur la machine, un simple accès SSH suffit. La gestion des clés et mots de passe se trouve ainsi centralisée dans Jenkins.
Lancer le script fait donc parti d’un job Jenkins. On pourra ainsi créer des workflows avec une succession de jobs.

Installation et configuration du plugin

Pour installer le plugin, rendez-vous dans la partie Administrer Jenkins, Gestion des plugins, puis dans l’onglet Disponible. Cochez la ligne devant le plugin, puis cliquez sur le bouton Installer qui se trouve tout en bas de la page.

Une fois le plugin installé, il faut configurer la liste des hôtes que nous voulons utiliser dans nos Builds. Pour cela, rendez vous dans la partie Administrer Jenkins, Configurer le système. Vous avez accès une section SSH Remote hosts dans laquelle nous allons déclarer les hôtes. Les boutons Ajouter et Supprimer permettent de gérer facilement la liste. Ensuite, il n’y a plus qu’à remplir les hôtes avec les informations suivantes :

Hostname : serveur hébergeant votre Tomcat (Obligatoire),
Port : d’écoute SSH (Optionnel, 22 par défaut),
User Name : nom de l’utilisateur qui sera connecté au serveur (Obligatoire),
Password/Passphrase : si vous utilisez une authentification simple, c’est ici qu’on ajoute le mot de passe, sinon cela peut aussi être la passphrase (Optionnel),
Keyfile : si vous utilisez une authentification avec clé privée, on ajoute ici le chemin vers la clé qui doit se trouver sur le même serveur que Jenkins (Optionnel).

Petit inconvénient, il est impossible de créer un alias pour la configuration de chaque serveur. De plus, la liste des hôtes est unique pour toute l’instance Jenkins. Si plusieurs projets sont présents sur l’instance, avec des noms d’hôtes relativement similaire, cela peut nuire à la lisibilité.

Exploitation du script

Après avoir installé votre script sur la machine Tomcat et avoir déclaré ce serveur Tomcat dans Jenkins, nous allons maintenant configurer l’invocation du script.
Pour cela, il suffit de créer un projet Free-style dans Jenkins, de cocher l’option Execute shell script on remote host using SSH.
Sélectionnez ensuite l’hôte qui vous intéresse, puis dans la partie Post-build script, ajoutez la commande de lancement de votre script shell (par exemple /usr/local/script/deploy_on_tomcat ).
Vous pouvez lancer le job pour vérifier son fonctionnement.
Nous avons créé un job séparé ici, mais rien ne vous empêche de l’intégrer directement dans votre build Jenkins principal. Si vous déclenchez une intégration continue à chaque commit sur le dépôt de source, vous allez ainsi faire du déploiement continu sur votre serveur.
Si l’on possède plusieurs machines, il faudra par contre créer plusieurs jobs différents (c’est-à-dire créer plusieurs projets Free Style). L’hôte n’est pas paramétrable.

Conclusion

Pour résumer, nous pouvons dresser le bilan suivant de l’utilisation du jenkins-ssh-plugin pour automatiser le déploiement depuis Jenkins sur des serveurs Tomcat :

Avantages

Simple et rapide à mettre en place,
Pas d’agent à installer sur les serveurs,
Gestion centralisée des accès aux machines,
Se branche facilement sur l’intégration continue pour un déploiement continu en 0 clic,
Compatible avec un mode de livraison en production (avec un bon script bien robuste, rien n’est impossible !).

Inconvénients

Liste statique des hôtes
Tous les hôtes sont à un seul endroit dans la configuration, cela devient compliqué à gérer avec un nombre croissant d’environnements,
Le job est lié à la machine sur laquelle il exécute le script,
Impossible de déployer l’application sur plusieurs machines, sauf à créer plusieurs jobs,
Le script doit être déployé préalablement sur le(s) serveur(s) Tomcat.

Retour Atelier Continuous Delivery – Partie 1 – Déploiement avec Apache Tomcat Maven Plugin

Julia Mateo — Fri, 25 Nov 2011 08:00:51 +0000

Les 13 et 20 octobre derniers a eu lieu le deuxième Tech Event Xebia avec, cette fois, comme sujet le Déploiement Continu sur Tomcat avec Jenkins, Rundeck et Deployit. Pour l’occasion nous avons eu la collaboration spéciale de deux guest stars :

Olivier Lamy, architecte chez Talend, membre de la fondation Apache et committer sur Tomcat et sur Jenkins
Vincent Behar, ingénieur Java à Exalead, owner du plugin Rundeck pour Jenkins et cofondateur de Paris Devops,

Merci à eux pour leur participation à la préparation de l’atelier ainsi qu’à sa présentation.

Flickr est l’exemple le plus évoqué à l’heure actuelle de déploiement continu. Il existe bien d’autres exemples connus comme Outbrain, Wealthfront ou Etsy. Même si le nombre d’entreprises qui arrivent à ce niveau de maturité est encore faible, il est possible qu’à l’avenir cette méthode devienne une technique courante dans les projets avec la progression de l’agilité. Son implémentation oblige, en effet, à accomplir quelques principes du manifeste agile, dont par exemple :

Une attention continue à l’excellence technique et à la qualité de la conception améliore l’agilité.
Un logiciel fonctionnel est la meilleure unité de mesure de la progression du projet.

Ainsi qu’à en pousser d’autres :

Livrez fréquemment un logiciel opérationnel avec des cycles de quelques semaines à quelques mois et une préférence pour les plus courts.
Notre première priorité est de satisfaire le client en livrant tôt et régulièrement des logiciels utiles.

Quels sont les points forts du déploiement continu ?

Etre au plus près des attentes du marché (le fameux Time to market) en fournissant aux utilisateurs les fonctionnalités qu’ils attendent dès qu’elles sont prêtes.
Minimiser le risque d’échec d’un gros déploiement.
Avoir un retour rapide des utilisateurs réels de l’application sur les nouvelles fonctionnalités de la version.
Une livraison fréquente permet aux utilisateurs de s’habituer progressivement aux nouveaux environnements ergonomiques.

En revanche, l’implémentation du déploiement continu ne doit pas être sous-estimée. Sa mise en place oblige à une grande rigueur :

Automatisation de toutes les phases de build, test et déploiement,
Configuration centralisée du déploiement et exécution sur chaque environnement,
Une haute disponibilité de l’infrastructure de production afin d’éviter les coupures de service,
Une couverture des tests exemplaire. Si les tests unitaires, d’intégration et d’acceptance passent, l’application répond aux besoins et peut en théorie partir en production à tout moment.
Communication fluide entre l’exploitation, les DBAs et les développeurs. Dans la ligne de ce que le mouvement Devops préconise, on doit éviter les fractures organisationnelles et développer un environnement collaboratif en donnant priorité au bon fonctionnement du système.

Notre atelier

Présentation globale de l’architecture

Revenons sur l’atelier. Le but de la soirée, par binôme, est de mettre la main à la pâte et configurer du déploiement continu. Pour ce faire, nous avons présenté comment déployer sur Tomcat l’application web modèle de Spring petclinic sur des instances Amazon EC2. Les méthodes proposées étaient les suivantes :

Le plugin Tomcat Maven
Le plugin SSH pour Jenkins
Rundeck et le plugin Rundeck pour Jenkins
Deployit, de XebiaLabs

Afin de tester les différents outils, voici l’architecture utilisée:

Une instance Amazon avec un Nexus pour gérer les artifacts de tous les assistants.
Un repository xebia-petclinic-X sur GitHub pour chaque équipe/binôme (où chaque équipe avait un numéro X associé)
Une instance Amazon EC2 avec un Jenkins, un Rundeck et un Deployit par équipe
Trois instances Amazon EC2 dont deux avaient un Tomcat qu’on a appellé “valid” (ou de production) et le troisième un Tomcat de “dev” (ou d’intégration/qualité)

Cette infrastructure est générée à chaud au début de chaque atelier avec un script écrit en java. Pour vous faire une idée, le nombre de nœuds créés pour chaque atelier a été autour des 45 (20 participants regroupés en binômes). Le démarrage des instances Amazon Linux a été fait avec le package d’AWS SDK pour Java. Pour l’initialisation et configuration de Nexus, Jenkins, Rundeck et Tomcat, nous avons utilisé le package d’Ubuntu Cloud-init. Puisque le serveur Nexus est partagé par tous les utilisateurs de l’atelier, une adresse Elastic-IP d’Amazon lui est assignée à son démarrage. La création automatique de chaque repository github par binôme a été faite avec l’API V2 de GitHub. Pour ceux intéressés à avoir plus des détails sur la création et l’initialisation des instances Amazon pour ce workshop, sachez que dans les prochains jours nous publierons à ce propos un nouveau billet.

Présentation de Apache Tomcat Maven Plugin

La première méthode de déploiement proposée utilise le plugin Apache Tomcat Maven. Olivier Lamy nous a fait une présentation des fonctionnalités de ce plugin qui facilite les opérations sur les wars quand on déploie sur Tomcat. Voici quelques-uns des goals disponibles :

tomcat:run permet de déployer un war sur un tomcat embarqué. Le plugin délègue à maven le téléchargement automatique des jars pour pouvoir l’exécuter. Cela permet le rechargement à chaud des jsp, css, html …
tomcat:deploy déploie un war dans un tomcat démarré.

Ainsi que les nouvelles fonctionnalités à venir :

Support pour tomcat 7
Un nouveau goal qui permettra de créer un jar standalone pour pouvoir exécuter le war sur tomcat. Le jar inclura la webapp aussi que tous les jars de tomcat nécessaires.
Par exemple : mvn tomcat7:exec-war génère un jar my-project-exec-war.jar
jar -jar my-project-exec-war.jar lance le tomcat avec la webapp avec une configuration par défaut. Il est aussi configurable en renseignant des paramètres (-httpPort -ajpPort…)

Durant le workshop, nous avons utilisé le goal « tomcat : deploy » afin de déployer l’application exemple en local, puis sur l’instance Amazon avec le Tomcat de Dev. Pour cela, il suffit de rajouter le plugin tomcat maven au pom.xml du projet comme ci-dessous :


     org.apache.tomcat.maven
     tomcat6-maven-plugin
     2.0-SNAPSHOT
     
          true

A noter qu’il faut aussi avoir installé Tomcat Manager sur l’instance Tomcat cible puisque le goal utilise le Tomcat Manager de l’instance et un upload HTTP pour déployer le war sur le serveur dont l’url sera spécifiée dans le paramètre -Dmaven.tomcat.url. Le login et le password pour Tomcat Manager devront aussi être passés dans la commande :

mvn tomcat6:deploy -Dtomcat.password=admin -Dtomcat.username=admin -Dmaven.tomcat.url=http://ecX-XX-XX-XXX.eu-west-1.compute.amazonaws.com:8080/manager

Ce goal peut aussi être rattaché à la phase de deploy d’un profil en particulier (dans l’exemple ci-dessous, tdeploy) :

mvn deploy -Ptdeploy

Si vous souhaitez refaire la manipulation chez vous, il vous suffit de cloner le projet, depuis https://github.com/xebia-france-training/xebia-petclinic-lite.

Puis exécuter le goal précédemment donné pour effectuer la manipulation.

Conclusions

Suite à l’exercice de déploiement avec le plugin, nous pouvons faire les conclusions suivantes:

Déploiement avec Tomcat Maven Plugin


Simple à mettre en place Simple à utiliser	Tomcat Manager est déconseillé en production Tomcat Manager ne redémarre pas la JVM : risque de fuite de mémoire Mode léger pour la production (login/password) Il n’est pas très adapté au cluster : impossibilité de déployer sur plusieurs instances en parallèle

Si on compare le déploiement via ce plugin avec les méthodes que nous présenterons dans nos prochains billets (le plugin SSH pour Jenkins, Rundeck ou Deployit), vous verrez qu’il s’éloigne quelque peu des méthodes habituelles d’installation d’un livrable en production. Une mise en production se résume rarement à simplement déployer un war sur un seul serveur Tomcat via HTTP. En effet, l’application pourrait être clusterisée, il pourrait y avoir besoin de copier des fichiers de configuration supplémentaires, ou encore de passer des scripts SQL. Comme vous le verrez après, les autres alternatives se basent sur un script shell qui laisse la porte ouverte à d’autres opérations.

Dans nos prochains billets, nous vous présenterons le déploiement via le plugin SSH pour Jenkins, Rundeck ainsi qu’un dernier article dédié à la création automatique de l’infrastructure utilisée dans ce workshop.

Deployer un artefact sur repo1.maven.org

Issam El Fatmi — Wed, 22 Jun 2011 17:30:28 +0000

Vous avez peut-être eu l’obsession de voir « maven » en train de télécharger vos propres artefacts à partir de son repository central. Du moins vous vous êtes sûrement posé la question : mon projet est mavenisé, open source, sur une forge publique (github, googlecode, etc.) et il est destiné à être utilisé par le plus grand nombre ; pourquoi ne pas le publier sur le Maven Central Repository (http://repo1.maven.org) ?

Au lieu de penser à ouvrir votre Nexus sur Internet ou encore à créer votre propre repository sur Google Code ou autre, nous vous proposons de directement déployer sur le Maven Central Repository, ce qui, en plus de vous épargner l’installation d’un repository, facilitera l’utilisation de votre artefact.

Le but de ce billet est de décrire la marche à suivre pour la publication d’un artefact en passant par le repository de Sonatype. Ce dernier étant un repository approuvé pour tout projet OSS comme c’est le cas du repository Apache (pour les projets Apache) et celui du Codehaus (pour les projets Codehaus). Le fait de passer par Sonatype vous garantit d’une part, un processus de validation structurant qui impose un ensemble de points de contrôle (licence, copyright, traçabilité, etc.) augmentant ainsi la qualité des métadonnées, et d’autre part une synchronisation rapide avec le Maven Central Repository.

Il s’agit également de vous faire profiter de notre expérience sur le sujet avec le déploiement de quelques artefacts tels que mindmap-maven-plugin, xebia-management-extras, xebia-spring-security-extras et xebia-servlet-extras.

Ce qui est présenté par la suite est basé principalement sur le guide officiel fourni par Sonatype: https://docs.sonatype.org/display/Repository/Sonatype+OSS+Maven+Repository+Usage+Guide

Choix de la licence du projet

Chacun appliquera sur son code la licence qui lui convient. C’est à la fois un choix « tactique » pour cibler ses utilisateurs et « philosophique » selon ses convictions. Pour résumer ce sujet qui mériterait un billet complet, il y a deux grandes familles de licences :

les licences « business friendly » (Apache Software Licence, MIT, BSD, etc) qui facilitent l’intégration dans toute programme (y compris « close source » et commercial)
les licences « business unfriendly » (GPL, Aferro GPL, etc) qui sont qualifiées de virales et ne permettent pas l’intégration dans des logiciels « close source »

Pour aller plus loin sur le sujet, nous vous recommandons 451 Chaos Group – 06/2011 : The trend towards permissive licensing et notre récent billet Réponses au Quizz Licences Open Source.

Application de la licence sur les fichiers de son projet

Tous les fichiers doivent porter le header de la licence
Un fichier LICENSE (exemple) à la racine doit être reporté dans les artefacts générés
Un fichier NOTICE (exemple) à la racine doit mentionner les copyrights des dépendances

Si vous êtes dans le cas d’une licence APV2, vous pouvez toujours vous référer à ce lien : Applying the license to new software.

Le apache-rat-plugin permet de vérifier la conformité du projet et peut casser le build dans le cas contraire.

Exemple de déclaration des ressources dans un pom maven pour intégrer les fichiers LICENSE et NOTICE dans les artefacts:


 ...
 
  
   ${basedir}/src/main/resources
   true
  
  
   ${basedir}
   META-INF
   
    LICENSE
    NOTICE
   
  
 
 ...

Exemple d’utilisation du apache-rat-plugin dans un pom maven:


   ...
   
    org.apache.rat
    apache-rat-plugin
    0.7
    
     
      verify
      
       check
      
     
    
   
   ...

Mise en conformité du pom maven

Le fichier pom.xml doit obligatoirement porter les informations suivantes:

Pour faciliter le déploiement des artifacts sur le repository http://oss.sonatype.org qui sert de bac à sable de validation, le plus simple est de référencer le pom parent « org.sonatype.oss:oss-parent » fourni par sonatype. Exemple :


  
    org.sonatype.oss
    oss-parent
    7
  
  ...

(?) De plus, il est fortement recommandé que le pom.xml ne référence pas de repository (cf. Why Putting Repositories in your POMs is a Bad Idea)

Signature des artefacts avec GPG

Les artefacts publiés sur repo1.maven.org doivent être signés.

Le pom parent org.sonatype.oss:oss-parent utilise le maven-gpg-plugin qui se base sur l’implémentation GnuPG du standard OpenPGP pour la signature des artefacts. Pour s’appuyer dessus, vous devez :

Installer un client GPG (e.g. Mac GNU Privacy Guard)
Créer votre paire de clés GPG (privée/publique) (cf GPG Quick Start par Paul Heinlein)
Distribuer votre clé publique sur un serveur de clé PGP:

gpg --keyserver hkp://pool.sks-keyservers.net --send-keys your_public_key_ID

Tester votre clé avec maven-gpg-plugin:

mvn package gpg:sign -Dgpg.passphrase=PASSPHRASE

Création d’un compte sur oss.sonatype.org

La création d’un compte pour déployer sur oss.sonatype.org se fait en créant un compte https://issues.sonatype.org/ .

Création d’un ticket Jira de demande d’autorisation : obligatoire pour la première publication

Il vous faut faire une demande à Sonatype en créant un ticket Jira de demande de publication d’artefact dans lequel on précise :

Summary : description rapide du projet
GroupId : groupId du projet Maven. Ce groupe doit reprendre le nom de domaine du projet (e.g. : fr.xebia, com.googlecode.myproject, etc.)
Project URL : l’url du projet (e.g. http://xebia-france.googlecode.com/
SCM URL : l’url du gestionnaire de source (e.g. http://xebia-france.googlecode.com/svn/)
Nexus Username : le ou les logins de connexion au JIRA : https://issues.sonatype.org/
Already Sync To Central : indique si des versions de l’artefact ont déjà été déployées sur le Maven Central Repository (si oui, Sonatype les réintégrera dans le fichier maven-metadata.xml)
Description : toute information complémentaire

Exemple de demande : OSSRH-995 : Managements extras : jmx-ification of util.concurrent / dbcp / jms, @Profiled annotation, etc

Déploiement des snapshots et des staging releases avec maven

Compléter l’élément SCM avec les informations de votre repository

Subversion:


  ...
  
    scm:svn:http://host_name/svn/path_to_project/trunk/
    scm:svn:https://host_name/svn/path_to_project/trunk/
    http://host_name/svn/path_to_project/
  
  ...

Github:


  ...
  
    scm:git:git@github.com:user/project_name.git
    scm:git:git@github.com:user/project_name.git
    git@github.com:user/project_name.git
  
  ...

Configurer le fichier settings.xml

Accès au repository nexus de sonatype:


  ...
  
    
      sonatype-nexus-snapshots
      your_jira_id
      your_jira_pwd
    
    
      sonatype-nexus-staging
      your_jira_id
      your_jira_pwd
    
  
  ...

Accès au repository du code source


  ...
  
    
      host_name_of_your_scm_url
      user_name
      password
    
  ...

Préparer la release: Création d’un nouveau tag sur le repository du code source

mvn release:prepare -Dresume=false (alternativement mvn release:clean release:prepare)

Déployer le nouveau tag dans le staging repository

mvn release:perform -Darguments=-Dgpg.passphrase=<>

Publication de votre artefact : utilisation de nexus-maven-plugin

Ajouter org.sonatype.plugins dans la section du fichier settings.xml


  ...
  
    org.sonatype.plugins
  
  ...

Afficher la liste des staging repositories : un staging repository par artefact

mvn nexus:staging-list

Ce qui vous permettra d’obtenir la liste des repositories ouverts et clôturés si il en existe :

Clôturer un staging repository

mvn nexus:staging-close

Sélectionnez à partir de la liste le repository à clôturer et suivre les instructions:

Publier l’artefact : action irréversible (aucun update ou delete ne sera possible)

mvn nexus:staging-promote

Sélectionnez le repository à publier:

Vous pouvez maintenant retrouver votre actefact sur le releases repository de Sonatype en attendant la synchronisation avec le repo1.maven.org qui vous permettra après quelques heures de le voir à partir du Maven Central Repository Browser

Activer la synchronisation avec le repository central repo1.maven.org

Pour une première publication, vous avez besoin de compléter le ticket JIRA précédemment créé par un commentaire afin de communiquer à Sonatype que votre staging repository est passé en « released ». Après étude, Sonatype activera la synchronisation centrale et fermera votre ticket.

Désormais, vos futures publications seront synchronisées automatiquement (pas besoin de création de ticket JIRA pour les prochaines releases).

Et l’impact du clash entre Sonatype et la Fondation Apache dans tout ça ?

La Fondation Apache et la société Sonatype sont en grand froid en ce moment (Maven Dev Mailing List : PMC change explanation). Nous ne polémiquerons pas sur le sujet. Nous n’avons pas vu d’impact sur la publication d’artefacts sur la Maven Central Repository (maven.org est géré par Sonatype, et non par la Fondation Apache).

Le Mind Mapping appliqué aux dépendances des projets « mavénisés »

Issam El Fatmi — Thu, 05 May 2011 17:15:54 +0000

Comme vous l’avez peut-être constaté dans vos applications d’entreprise, les dépendances des modules sont parfois difficiles à appréhender, de par leur nombre et la complexité des relations.

Encore plus si vous vous retrouvez face à un chantier de refactoring important qui touche à votre application en sa globalité (refonte du modèle métier, éclatement de modules, restructuration des couches logicielles, migration de framework, externalisation des traitements communs en aspect, …) ; assurer la réussite d’un tel chantier s’avère généralement une tâche difficile : vous avez beau essayé de pousser l’étude d’impact au bout, les surprises sont toujours au rendez-vous.

Garder un œil sur l’application en phase de transformation implique systématiquement une prise de « snapshots » réguliers des dépendances entre modules ; cela vous permettra sans doute de savoir rapidement si vous êtes sur la bonne voie, ou si un « break – rethink to avoid worse » est nécessaire.

C’est dans cette optique que le Mind Mapping s’impose afin de fournir une vue documentaire visuelle facilement exploitable des dépendances des modules ; vous permettant ainsi de contrôler la tendance du projet et d’éviter toute apparition de dépendance cyclique directe ou indirecte (transitive), du moins la faire disparaître assez rapidement si elle est déjà là.

De ce fait, on s’aperçoit que cette approche a plus de valeur ajoutée pour le Lead technique ou encore l’architecte de l’équipe de développement que pour le développeur. Quant à ce dernier, et si besoin (on ne s’amuse pas à faire des « mvn dependency:tree » tous les jours), il pourrait rester fidèle aux outils qui viennent accompagner son IDE, que ce soit sous forme de plugin (Jdepend, byecycle, M2Eclipse avec Dependency graph view et Dependency Hierarchy view, …) ou encore en standalone (JDepend, mvn dependency:tree, …).

Dans cet article, on s’intéresse particulièrement aux projets « mavénisés ». La démarche consiste, pour un module donné, à produire un artefact pouvant être exploité par un outil open source de Mind Mapping. L’idée est donc de développer un simple plugin maven en charge de générer un fichier au format attendu pour l’outil. Il existe plusieurs logiciels open source de Mind Mapping à savoir FreeMind, FreePlane (un dérivé de FreeMind), Xmind, etc. Le choix est fait sur FreePlane qui traite des fichiers de type « .mm ».

La « Mind Map »: Un véritable couteau suisse de la pensée

La Mind Map se veut une représentation visuelle externe de ce qui se passe dans le cerveau. Ainsi, on peut s’en servir pour refléter la pensée, la réflexion, la connaissance, la mémoire et stimuler la créativité.
Les cartes mentales « Mind Maps », ou encore les cartes heuristiques, représentent par définition, une méthode graphique pour prendre des notes. Leur base visuelle permet de distinguer des mots ou des idées, souvent avec des couleurs et des symboles. Elles prennent généralement un format de niveau hiérarchique ou d’un arbre, avec des idées de ramification.
Les cartes mentales sont des collections de mots structurés par le contexte mental de l’auteur avec des mnémoniques visuels, des couleurs, des icônes et des liens.
Ces cartes diffèrent des cartes conceptuelles, dans l’esprit, du fait qu’elles se concentrent sur une seule idée, alors que les cartes conceptuelles en communiquent plusieurs. Elles ont également une finalité différente : elles aident à la mémoire et à l’organisation.

Ci-dessous une Mind Map concernant les usages possibles du Mind Mapping :

Mind Map Maven Plugin

Les API nécessaires

maven-dependency-tree.jar: utilisé pour construire l’arbre des dépendances d’un module donné et en récupérer le « root node »
maven-plugin-api.jar: API de plugin Maven
velocity-tools.jar : utilisation du moteur de substitution Velocity (Velocity Templating Engine) pour la génération de l’artefact final à partir d’un template.

pom.xml



    4.0.0
    maven-plugin
    fr.xebia.maven.plugins
    mindmap-maven-plugin
    1.0.0-SNAPSHOT
    Maven dependency :: ${project.artifactId} ${project.packaging}
    
        This plugin generates a MindMap from the project
        dependencies. The mindmap file (with the '.mm' extension)
        can be viewed with Freeplane (free tool).
        By default, the mindmap shows the full dependency tree.
        You can filter this tree at generation time
        by artifact's group id, by providing a parameter
         'groupIdsFilteringREGEXMatch'
        setted with a groupId name fragment (a startswith will be performed).
        Usage is (for exemple) :
        mvn fr.xebia.maven.plugins:mindmap-maven-plugin:1.0.0-SNAPSHOT:mindmap
        with filtering :
        mvn fr.xebia.maven.plugins:mindmap-maven-plugin:1.0.0-SNAPSHOT:mindmap -DgroupIdsFilteringREGEXMatch=fr.xebia
    
    
        
            org.apache.maven.shared
            maven-dependency-tree
            1.2
        
        
            org.apache.maven
            maven-plugin-api
            2.2.1
        
        
            org.apache.velocity
            velocity-tools
            2.0

MindmapMojo.java

package fr.xebia.maven.plugin.mindmap;
import java.io.FileWriter;
import java.io.IOException;
import java.text.SimpleDateFormat;
import java.util.Calendar;
import java.util.Properties;
import org.apache.maven.artifact.metadata.ArtifactMetadataSource;
import org.apache.maven.artifact.repository.ArtifactRepository;
import org.apache.maven.artifact.resolver.ArtifactCollector;
import org.apache.maven.artifact.resolver.filter.ArtifactFilter;
import org.apache.maven.artifact.resolver.filter.ScopeArtifactFilter;
import org.apache.maven.plugin.AbstractMojo;
import org.apache.maven.plugin.MojoExecutionException;
import org.apache.maven.project.MavenProject;
import org.apache.maven.shared.dependency.tree.DependencyNode;
import org.apache.maven.shared.dependency.tree.DependencyTreeBuilder;
import org.apache.maven.shared.dependency.tree.DependencyTreeBuilderException;
import org.apache.velocity.Template;
import org.apache.velocity.VelocityContext;
import org.apache.velocity.app.VelocityEngine;
import org.apache.velocity.tools.generic.SortTool;
/**
 * Generate a mindmap from the pom dependencies.
 *
 * @goal mindmap
 *
 */
public class MindmapMojo extends AbstractMojo {
    /** @component */
    private org.apache.maven.artifact.factory.ArtifactFactory artifactFactory;
    /**
     * @component
     * @required
     * @readonly
     */
    private ArtifactMetadataSource artifactMetadataSource;
    /**
     * @component
     * @required
     * @readonly
     */
    private ArtifactCollector artifactCollector;
    /**
     * @component
     * @required
     * @readonly
     */
    private DependencyTreeBuilder treeBuilder;
    /** @parameter default-value="${localRepository}" */
    private ArtifactRepository localRepository;
    /**
     * @parameter default-value="${project}"
     */
    private MavenProject project;
    /**
     * @parameter expression="${groupIdsFilteringREGEXMatch}"
     */
    private String groupIdsFilteringREGEXMatch = null;
    public void execute() throws MojoExecutionException {
        try {
            ArtifactFilter artifactFilter = new ScopeArtifactFilter(null);
            // Build project dependency tree
            DependencyNode rootNode = treeBuilder.buildDependencyTree(project,
                    localRepository, artifactFactory, artifactMetadataSource,
                    artifactFilter, artifactCollector);
            generateMindMapXML(project, rootNode);
        } catch (DependencyTreeBuilderException e) {
            throw new MojoExecutionException("Unable to build project dependency tree.", e);
        }
    }
    private void generateMindMapXML(MavenProject mavenProject, DependencyNode rootNode) throws MojoExecutionException {
        FileWriter fw = null;
        try {
            Properties p = new Properties();
            p.setProperty("resource.loader", "class");
            p.setProperty("class.resource.loader.class",
            "org.apache.velocity.runtime.resource.loader.ClasspathResourceLoader");
            //  first, get and initialize an engine
            VelocityEngine ve = new VelocityEngine();
            ve.init(p);
            //  next, get the Template
            Template freePlaneTemplate = ve.getTemplate("MindMapTemplate.vm");
            // create a context and add data
            VelocityContext context = new VelocityContext();
            context.put("artifactId", mavenProject.getArtifactId());
            context.put("sorter", new SortTool());
            context.put("rootNode", rootNode);
            context.put("date", (new SimpleDateFormat("dd/MM/yy HH:mm")).format(Calendar.getInstance().getTime()));
            context.put("groupIdsFilteringREGEXMatch", (groupIdsFilteringREGEXMatch != null)?groupIdsFilteringREGEXMatch:"");
            context.put("creationTS", Calendar.getInstance().getTimeInMillis());
            // now render the template
            fw = new FileWriter("./"+mavenProject.getGroupId()+"_"+mavenProject.getArtifactId()+"_"+mavenProject.getVersion()+".mm");
            // write the mindmap xml to disc
            freePlaneTemplate.merge(context, fw);
        } catch (Exception e) {
            throw new MojoExecutionException("Unable to generate mind map.", e);
        } finally {
            if (fw != null) {
                try {
                    fw.close();
                } catch (IOException e) {
                    getLog().warn("Unable to properly close stream.", e);
                }
            }
        }
    }
}

FreePlane Velocity Template: MindMapTemplate.vm

#macro( exploreNodes $node )
    #set( $nodeCount = $nodeCount +1 )
    #set( $color = $nodeCount % 255 )
    #if ($node.artifact.groupId.startsWith($groupIdsFilteringREGEXMatch))
        
            
            
              
              
                
                  ## Mettre en gris clair le groupId
                  $node.artifact.groupId
                
                
                 ## Mettre en gras l'artifactId
                  $node.artifact.artifactId
                
                
                  ## Mettre en gris clair la version
                  $node.artifact.version
                
              
            
            
            #* Pour le noeud parent (root node) on rajoute un noeud supplémentaire à gauche du noeud parent
               et contenant le texte suivant:Generated : ${date}
               avec une icône calendar
            *#
            #if (!$rootNodeExplored)
                
                    
                
                #* Pour le noeud parent (root node), quand le filtre sur le groupeId est utilisé
                   on rajoute un noeud supplémentaire à gauche du noeud parent
                   et contenant le texte suivant:Only groups starting with [${groupIdsFilteringREGEXMatch}] are shown
                   avec une icône essagebox_warning
                *#
                #if( $groupIdsFilteringREGEXMatch.length() > 0)
                    
                        
                    
                #end
            #end
            #if (!$rootNodeExplored)
                #set( $rootNodeExplored = true )
            #end
            ## Parcours des noeuds fils du noeud en cours et appel récursif de la méthode: exploreNodes
            #foreach( $dependencyNode in $sorter.sort($node.children,"artifact.artifactId") )
                #exploreNodes($dependencyNode)
            #end
        
    #end
#end
#set( $nodeCount = 0 )
#set( $Integer = 0 )
#set( $rootNodeExplored = false )


#exploreNodes($rootNode)

Exécution du plugin

Sans le filtre:

mvn fr.xebia.maven.plugins:mindmap-maven-plugin:1.0.0-SNAPSHOT:mindmap

Avec le filtre:

mvn fr.xebia.maven.plugins:mindmap-maven-plugin:1.0.0-SNAPSHOT:mindmap -DgroupIdsFilteringREGEXMatch=fr.xebia

Attacher le goal « mindmap » à une phase spécifique du build Lifecycle


   
      
         fr.xebia.maven.plugins
         mindmap-maven-plugin
         1.0.0-SNAPSHOT
         
            
               package
               
                  mindmap

Il est possible de définir la phase par défaut du Mojo lors de sa déclaration. Le Mojo s’exécutera donc lors de cette phase à condition que l’on n’aie précisé aucune phase dans . Dans le cas contraire on parle de « rebinding » du Mojo avec une nouvelle phase du build Lifecycle.

/**
 * Generate a mindmap from the pom dependencies.
 *
 * @goal mindmap
 *
 * @phase package
 *
 */
public class MindmapMojo extends AbstractMojo {
}

Vous pourrez vous référer à la documentation de l’API Mojo pour en savoir plus sur l’ensemble des annotations possibles.

Raccourcissement de la ligne de commande

Vous avez sans doute remarqué que le préfixe d’exécution du plugin n’est pas très convivial aux utilisateurs ; le fait de taper

mvn ${groupId}:${artefactId}:${version}:${goal}

en l’occurrence:

mvn fr.xebia.maven.plugins:mindmap-maven-plugin:1.0.0-SNAPSHOT:mindmap

semble être parfois gênant.

Afin de donner aux utilisateurs un préfixe idéal ou encore un « shortened prefix » pour faire référence au plugin, il faut rajouter le groupId dans le fichier de configuration maven (settings.xml) comme suit :


   fr.xebia.maven.plugins

Désormais, vous pouvez exécuter le plugin en tapant:

mvn mindmap:mindmap

Pour plus d’informations sur la résolution des préfixes des plugins maven je vous invite à consulter la documentation officielle.

Exploitation des Fichiers .mm

On va appliquer le plugin sur lui-même, ce qui nous donnera l’aperçu suivant avec FreePlane :

Par la suite, vous avez la possibilité de naviguer dans les différents noeuds (déplier / plier), tout en ayant la souplesse de les éditer.
Par exemple, si vous dépliez le module velocity-tools, vous aurez l’ensemble de ses dépendances directes :

L’application du filtre groupIdsFilteringREGEXMatch=fr.xebia ne donnera que le module « mindmap-maven-plugin » lui même (comme il ne dispose d’aucune dépendance à un groupId commençant par fr.xebia):

Aller plus loin

Une fois que vous avez compris le mécanisme de fonctionnement du templating et avec un minimum de connaissances du langage VTL (Velocity Template Language), vous pouvez faire ce que vous voulez ; on pourrait imaginer par exemple de colorer les dépendances cycliques en insérant des flèches rouges liant les modules concernés (ajout des balises attendu par FreePlane), ou encore de développer des filtres plus avancés en fonction de vos besoins ; je vois bien un filtre sur le scope de la dépendance (compile, runtime, test, …).

Automatiser les tests Selenium avec Maven

Romain Schlick — Fri, 18 Feb 2011 09:33:36 +0000

Selenium regroupe une suite d’outils permettant de tester des applications web. Tout comme les tests unitaires, Selenium permet notamment de vérifier la non-régression d’une application et est un gage de qualité supplémentaire. Bien que la création des tests Selenium soit relativement simple, automatiser leur exécution sur un serveur d’intégration continue reste complexe à mettre en œuvre. Je vous propose une solution avec l’outil de build Maven. Disposant de nombreux plugins, comme SQL, Failsafe, Jetty et Selenium, Maven permet la mise en place d’une automatisation satisfaisante. Cette solution peut servir aussi aux tests d’intégration.

Selenium, un puissant outil pour créer des tests fonctionnels

Les tests Selenium reproduisent toutes sortes d’interactions qu’un utilisateur peut effectuer sur un navigateur web. Un test Selenium est constitué d’un script pouvant être écrit dans plusieurs langages (Java, Html, C#, Groovy, Php, etc.). Ce script est ensuite interprété par le serveur Selenium RC, qui s’occupe d’envoyer les bonnes commandes au navigateur. Les avantages de Selenium sont d’être compatible avec de nombreux navigateurs (Internet Explorer, Firefox, Chrome, etc.) et d’offrir un outil de création de test, appelé Selenium IDE. Ce dernier est disponible sous forme d’un plugin Firefox. Les scripts Selenium sont relativement simples à coder directement, puisqu’il s’agit à chaque fois d’indiquer le type d’interaction (clic, saisie, etc.), puis de sélectionner l’élément en jeu (lien, tableau, div, input, etc.), et enfin d’indiquer une éventuelle valeur. Cependant, on aurait souhaité la disponibilité de Selenium IDE sur d’autres navigateurs.

Vers une automatisation des tests Selenium avec Maven

L’exécution automatique des tests unitaires sur un serveur d’intégration continue est une pratique très répandue. En utilisant une base de données en mémoire, comme HSQLDB, les tests unitaires peuvent être exécutés facilement quel que soit l’environnement. De la même manière, il est intéressant de pouvoir lancer automatiquement ces tests fonctionnels sur un serveur d’intégration. Cependant, la mise en place est plus complexe: à chaque exécution, il faut au préalable s’assurer que la base de données soit dans un état cohérent (en terme de jeu de données), mais aussi que les serveurs web et Selenium RC soient démarrés.

Voici les étapes que nous allons automatiser à l’aide de l’outil Maven :

Initialiser la base de données avec un jeu de données : Plugin maven SQL.
Construire l’application web et la déployer sur un serveur web Jetty : Plugin maven Jetty.
Démarrer le serveur Selenium RC : Plugin maven Selenium
Exécuter les tests Selenium : Plugin maven Failsafe.

Comme vous pouvez le constater, cette solution repose sur l’outil de build Maven et le serveur web Jetty. Dans un précédent article, j’avais proposé une autre solution basée sur l’outil Ant. Avant d’aller plus loin, il est important de connaître le cycle de vie du build de Maven. Voici l’ordre d’exécution des principales phases du build :

validate
compile
package
test
pre-integration-test
integration-test
post-integration-test
verify
install
deploy

Lorsqu’on lance une phase, toutes les phases qui la précèdent sont exécutées au préalable. La phase test exécute les tests unitaires. Il existe aussi une phase integration-test qui va nous servir à exécuter les tests Selenium. Cette phase est précédée de la phase pre-integration-test et suivie de la phase post-integration-test qui vont respectivement nous aider à préparer puis nettoyer l’environnement d’exécution : démarrage et arrêt des serveurs Web et Selenium RC typiquement. Pour lancer les tests Selenium, il est nécessaire de lancer la commande mvn verify et non mvn integration-test, sinon la phase post-integration-test ne sera pas exécutée.

Je vais maintenant aborder l’intégration de chacune des briques (Selenium, base de données, et serveur web) dans Maven.

Intégration de Selenium dans Maven

L’intégration de Selenium dans Maven se décompose en deux étapes :

Déclarer l’exécution des tests Selenium via le plugin Failsafe.
Démarrer le serveur Selenium RC en pre-integration-test et l’arrêter en post-integration-test.

Solution 1: Exécuter les tests avec le plugin Surefire

Pour intégrer l’exécution des tests Selenium, il existe une première solution basée sur le plugin Surefire. La fonction première de ce plugin est d’exécuter les tests unitaires lors de la phase test et de générer un rapport. L’idée ici est de considérer les tests Selenium, comme des tests unitaires JUnit. Pour inclure les tests Selenium, il faut définir un plan d’exécution surefire-integration-test associé à la phase integration-test en incluant dedans les classes de test Selenium. Par ailleurs, il faut exclure les tests Selenium de la phase test (dans ). On obtient alors la déclaration du plugin suivant dans le pom :


   org.apache.maven.plugins
   maven-surefire-plugin
   
      
         
      
      
         com/xebia/selenium/**/*Test.java  
      
   
   
      
         surefire-integration-test
         integration-test
         
            test 
         
         
            false
            
               com/xebia/selenium/**/*Test.java

La solution Surefire n’est cependant pas optimale. En effet, Surefire a été conçu à l’origine uniquement pour les tests unitaires. Ce qui explique que si un test échoue, le build maven s’arrêtera à la phase integration-test, sans aller jusqu’au post-integration-test. Du coup, l’environnement d’exécution ne sera pas correctement nettoyé.

Solution 2 recommandée: Exécuter les tests avec le plugin FailSafe

Pour corriger les limitations de Surefire, un nouveau plugin FailSafe dédié aux tests d’intégration a été créé. Ce plugin est un fork de Surefire, qui ne bloque pas le cycle de vie du build en cas d’échec. En lançant les tests Selenium avec mvn verify et non mvn integration-test, on s’assure que la phase post-integration-test sera bien exécutée en cas d’erreurs. Le rôle de la phase verify est donc clairement de vérifier l’état d’exécution des tests d’intégration. Voici comment déclarer le plugin FailSafe dans le pom :


   org.apache.maven.plugins
   maven-failsafe-plugin
   2.7.2
   
      ${basedir}/target/surefire-reports
      
         com/xebia/selenium/**/*.java 
      
      
         ${jetty.port}
         ${artifactId}
      
   
   
      
         integration-test
         
            integration-test
         
      
      
         verify
         
            verify

Afin de rendre paramétrable certaines valeurs de contexte dans vos classes de tests Selenium, comme le port et le contexte de l’application, il est possible d’indiquer des propriétés systèmes dans le plugin FailSafe. Pour cela, il suffit d’ajouter l’élément dans avec les différentes propriétés.
On remarque aussi la propriété qui permet de générer les rapports de tests dans le même dossier que Surefire. Le serveur d’intégration inclura ainsi les résultats des tests Selenium avec ceux des tests unitaires. Une autre solution est de définir l’emplacement des rapports directement sur le serveur d’intégration continue. Par défaut, FailSafe place les rapports dans basedir/target/failsafe-reports.

Ajout du plugin Selenium (Pour démarrer et arrêter le serveur Selenium RC)

Afin de lancer automatiquement le serveur Selenium RC pendant l’exécution de la phase integration-test, il faut ajouter le plugin suivant dans le pom :


   org.codehaus.mojo
   selenium-maven-plugin
   1.0.1
   
      
         start
         pre-integration-test
         
            start-server
         
         
            true
         
      
      
         stop
         post-integration-test
         
            stop-server

L’option true permet de ne pas bloquer le processus Maven pendant que le serveur Selenium RC est démarré.

Configuration du serveur web avec le plugin Jetty

Préalablement à l’exécution des tests Selenium, il est nécessaire de démarrer l’application sur un serveur web durant la phase pre-integration-test. Le serveur sera arrêté durant la phase post-integration-test. Voici la manière de déclarer le plugin Jetty dans le pom :


   org.mortbay.jetty
   maven-jetty-plugin
   6.1.10
   
      10
      foo
      9999
      ${webapp.dir}
      
         
            ${jetty.port}
            60000
         
      
   
   
      
         start-jetty
         pre-integration-test
         
            run
         
         
            0
            true
         
      
      
         stop-jetty
         post-integration-test
         
            stop

L’attribut permet d’indiquer le chemin de l’application web. On peut aussi remarquer l’utilisation d’une propriété jetty.port pour mettre en paramètre le port d’écoute de Jetty. Celle-ci se déclare de la manière suivante dans le pom.xml :


   9090
   ......

Manipulation de la base de données

Il existe de nombreuses solutions pour préparer la base de données aux tests d’intégration. Même s’il est possible d’utiliser une base de données en mémoire, comme HSQLDB, je recommanderais plutôt d’utiliser le même type de base qu’en production, parce que nous exécutons des tests end-to-end. Pour insérer les jeux de données, il est possible d’utiliser deux plugins Maven : SQL ou DbUnit. J’ai privilégié l’utilisation du plugin SQL, car mes scripts étaient déjà écrits en SQL. En effet, DbUnit utilise son propre format en XML.
Le plugin SQL permet aussi d’exécuter des procédures stockées et des fonctions en changeant le type de délimiteur, qui est par défaut ‘;’. Dans , on définit le driver, ainsi que les paramètres de connexion. J’ai ajouté une dépendance au driver d’Oracle dans mon exemple. Le paramètre permet d’indiquer si l’on veut que les scripts soient exécutés de manière transactionnelle ou non.
Ensuite, il suffit de déclarer un plan d’exécution ‘insert_data’ pour la phase pre-integration-test et un autre ‘drop_data’ pour la phase post-integration-test en indiquant les scripts SQL.


   org.codehaus.mojo
   sql-maven-plugin
   1.4
   
      
         com.oracle
         ojdbc14
         10.2.0.4
      
   
   
      oracle.jdbc.driver.OracleDriver
      jdbc:oracle:thin:@localhost:1521:capitaineHadoc
      tintin
      milou
      ;
      normal
      true
      ${maven.test.skip}
      true
   
   
      
         insert-data
         pre-integration-test
         
            execute
         
         
            ascending
            
               ${basedir}/path/to/sql/files
               
                  insert-data.sql
               
            
         
      
      
         drop-data
         post-integration-test
         
            execute
         
         
            ascending
            
               ${basedir}/path/to/sql/files
               
                  drop-data.sql

Execution des tests Selenium

Depuis Maven

Après avoir déclaré tous les plugins dans le pom.xml, il suffit de lancer la commande suivante :

mvn verify

Voici alors une synthèse des logs que l’ont obtient :

[INFO] [selenium:start-server {execution: start}]
[INFO] 1
[INFO] [jetty:run {execution: start-jetty}]
[INFO] [failsafe:integration-test {execution: integration-test}]
[INFO] [selenium:stop-server {execution: stop}]
[INFO] 1
[INFO] [jetty:stop {execution: stop-jetty}]
[INFO] [failsafe:verify {execution: verify}]
[INFO] Failsafe report directory: D:Javasoftworkspacepid-trunktargetsurefire-reports

Depuis votre IDE

Lorsqu’on développe de nouveaux tests Selenium ou tout simplement pour débugger, il est nécessaire de les exécuter sur son IDE. Pour parvenir à cela, il suffit de lancer les commandes suivantes (dans des terminaux différents) :

Préparer la base de données si nécessaire :
```
mvn sql:execute
```
Démarrer le serveur Selenium RC :
```
mvn selenium:start-server
```
Démarrer le serveur web Jetty :
```
mvn jetty:run
```
Exécuter le test depuis votre IDE.

Conclusion

Avec ses nombreux plugins, Maven est un puissant outil pour automatiser l’exécution des tests Selenium. Les solutions proposées dans cet article peuvent servir de manière générale aux tests d’intégration. Les prochaines versions de Maven ne prévoient pas une séparation des sources entre les tests unitaires et les tests d’integration (src/main/test vs src/main/it). En effet, le plugin FailSafe permet de gérer les tests d’intégration de manière dédiée.

Configurer automatiquement Eclipse avec Maven

Nathaniel Richand — Wed, 19 Jan 2011 13:58:22 +0000

En ce beau matin d’hiver, me voilà bien décidé à effectuer un peu de ménage sur notre projet. Ma cible d’aujourd’hui : la chasse aux warnings.

Grosso modo, j’observe qu’il y a 3 types de warning :

imports inutilisés (60%)
unchecked casts (30%)
variables ou méthodes private non utilisées (10%)

Je prends mon bâton de pèlerin et je nettoie. Cependant, je me rends bien compte que ces warnings sont pour la majorité des erreurs d’inattention qui pourraient être facilement évitées.

A quoi bon nettoyer, si c’est pour se retrouver dans la même situation dans trois mois ? Donc, en plus de ma maintenance corrective, je pars également à la recherche d’une action préventive.

Première idée évidente, configurer Eclipse pour que celui-ci effectue ce genre de nettoyage lors d’une sauvegarde d’un fichier. Facile, il suffit de paramétrer ceci dans Properties -> Java Editor -> Save Actions (Plus de détails ici).

Cependant, à quoi bon le faire uniquement sur mon Eclipse ? Quel intérêt, si les autres membres de l’équipe ne bénéficient pas eux aussi de la même configuration ? Comment faire en sorte que ma configuration soit facilement partagée avec les autres ?

Le projet étant un projet maven, le maven-eclipse-plugin semble offrir la solution.

Construire sa configuration cible idéale

Le plus facile est de le faire via Eclipse. On choisit un projet java et on se définit la configuration voulue dans les properties. Je ne vais pas vous conseiller particulièrement, ceci étant souvent une affaire de gout. Allez jeter un coup d’œil notamment dans :

Java Code Style : Clean Up, Code Templates, Formatter

Java Compiler -> Errors/Warning : pour redéfinir le niveau des alertes. Il peut être intéressant de bloquer directement depuis l’IDE certaines sources d’erreurs, comme par exemple : x == x ou x =x…

Java Editor -> Save Action (vu précédemment) :

Enregister sa configuration dans Maven

Une fois le paramétrage effectué, il suffit d’aller récupérer le résultat dans le répertoire .settings du projet. Vous trouverez dans ce répertoire les fichiers contenant la configuration réalisée précédemment (org.eclipse.jdt.ui.prefs, org.eclipse.jdt.core.prefs, etc.). Ce sont des fichiers de propriétés contenant ce genre d’information :

#Wed Dec 15 14:36:54 CET 2010
cleanup.add_default_serial_version_id=true
cleanup.add_generated_serial_version_id=false
cleanup.add_missing_annotations=true
cleanup.add_missing_deprecated_annotations=true
cleanup.add_missing_methods=false
cleanup.add_missing_nls_tags=false
cleanup.add_missing_override_annotations=true
cleanup.add_missing_override_annotations_interface_methods=true
...

Il suffit maintenant d’extraire tout le contenu nous intéressant et de le mettre dans la configuration du maven-eclipse-plugin. Par exemple :


  4.0.0
  fr.xebia.build.tools
  testConfMaven
  0.0.1-SNAPSHOT
  
    
      
        org.apache.maven.plugins
        maven-eclipse-plugin
        2.7
        
          true
          
            
              .settings/org.eclipse.jdt.ui.prefs

A noter, on peut également mettre cette configuration dans des fichiers externes, qui seraient embarqués dans une dépendance maven :


  maven-eclipse-plugin
  2.7
  
    
      
        .settings/org.eclipse.jdt.ui.prefs
        settings/org.eclipse.jdt.ui.prefs
      
      
        .checkstyle
        /.checkstyle
      
    
  
  
    
      fr.xebia.build.tools
      xebia-eclipse-conf
      0.0.1

Notre projet xebia-eclipse-conf est une dépendance maven du projet et possède la structure suivante :

Une fois la configuration faite, il suffira aux développeurs d’exécuter la commande mvn eclipse:m2eclipse ou mvn eclipse:eclipse (si vous n’utilisez pas m2Eclipse) puis de faire un refresh sur votre projet.

Nous utilisons la version 2.7 du maven-eclipse-plugin, car le goal eclipse:m2eclipse a été supprimé de la version 2.8 (voir l’explication de Jason van Zyl). Cependant, aucune autre alternative valable n’existe à notre connaissance pour générer les fichiers de configuration d’Eclipse. Le salut pourra venir des « Extension points », cependant cette solution ne paraît pas encore utilisable en l’état.

Point d’attention

Ce n’est pas parce que l’on peut tout faire, qu’il est souhaitable de tout mettre dans notre configuration. Le mieux est l’ennemi du bien, et il convient donc de trouver un juste équilibre entre ce qui est vraiment utile et ce qui pourrait devenir une contrainte pour certaines personnes. Quoi qu’il arrive, il est important que l’équipe valide ensemble le contenu plutôt qu’une personne isolée fasse selon ses goûts.

Voilà pour l’astuce ! Maintenant, vous allez me dire que dans votre équipe un vilain petit canard utilise Intellij Idea. Je ne connais pas encore le pendant de cette méthode. Peut-être que le maven-idea-plugin fait l’affaire. Si vous connaissez une solution viable, n’hésitez pas à poster la solution en commentaire.

Choisir son outil pour automatiser les déploiements

Emmanuel Servent — Wed, 01 Dec 2010 07:43:01 +0000

Depuis le traditionnel outil make, introduit en 1977 pour livrer en production un logiciel, plusieurs étapes, de la construction du logiciel au processus de livraison, ont été automatisées. En réalité, être professionnel lorsqu’on parle de développer des logiciels, c’est, a minima, savoir automatiser la compilation et les tests en intégration continue. Mais un autre sujet progresse aussi dans le domaine de la gestion du cycle de vie des applications (Application Lifecycle Management – ALM), il s’agit de l’automatisation des déploiements. Cette progression est en partie due à nos environnements (serveurs d’application, ESB, EAI, etc.) qui sont de plus en plus complexes et étendus. Le nombre croissant de nouvelles versions d’une application, demandées par le business moderne, et le fait que le déploiement doit être suffisamment fiable pour ne pas risquer d’interrompre un service en ligne sont deux raisons supplémentaires qui poussent à s’intéresser à cette question. Ajoutez à cela que les infrastructures en cloud gagnent un peu plus de terrain chaque jour, et vous conviendrez que l’on a encore un long chemin, à la fois motivant et intéressant, à parcourir.

Est-ce que nos outils de packaging actuels peuvent déployer nos applications?

Dans cet article, je souhaite comparer l’automatisation du déploiement au plus connu des processus automatiques du développement logiciel : le packaging de l’application. En simplifiant, le processus de packaging part du code source pour le transformer en code exécutable. La façon la plus simple pour créer ce code est d’utiliser un script shell qui lance le compilateur, mais ce processus a beaucoup mûri. Grâce à des outils comme Make, cité précédemment, mais aussi à Ant et Maven, l’utilisateur peut spécifier de manière très détaillée tout le processus. Prenons l’exemple de Maven, la plupart des projets n’ont plus besoin de scripter quoique soit. Le fichier POM décrit les composants du projet, les plugins utilisés, et la façon de packager l’application. Et en ce moment même, de nouveaux outils font leur apparition, comme Gradle, qui offre encore un peu plus de flexibilité.

Mais ces outils nous permettent-ils de faire du déploiement automatique? Dans un billet précédent, mon collègue Robert van Loghem a expliqué en quoi le déploiement est un processus complexe qui inclut un certain nombre d’étapes comme l’installation des EAR/WAR, la configuration des datasources et le redémarrage des serveurs.
Bien que Wikipedia inclut la fonction de déploiement vers des systèmes en production, lorsqu’il définit l’automatisation du packaging, les outils actuels n’ont pas intégré ces concepts de packages de déploiement (i.e. les livrables), les environnements cibles (test, recette, production, etc.) ou la modification des valeurs selon l’environnement. En réalité, ils n’ont pas de connaissances liées aux middlewares sur lesquels on déploie et ne proposeront certainement jamais des scenarii de déploiement. Au final, ce qu’offrent ces outils, c’est le moyen de scripter, bien connu des développeurs, et de stocker ces scripts avec les sources à installer. Cela amène irrémédiablement à de nombreux scripts « maison » pour automatiser les déploiements.

Mais ce n’est pas tellement surprenant. Dans Wikipedia, les pré-requis d’un système d’automatisation ne mentionnent pas le Déploiement. Un système de déploiement automatique a pour objectif de déployer du code exécutable sur un environnement cible, alors que le système d’automatisation du packaging ne fait que produire ce code exécutable.

Les pré-requis nécessaires pour que notre outil déploie

Voici une liste de pré-requis que devrait satisfaire un outil de déploiement automatique :

Avoir nativement les concepts de base du déploiement : packages, environnements, lien entre les middlewares, etc.
Support inclus pour les middlewares principaux avec une possibilité de l’étendre.
Support inclus pour les scenarii courants de déploiement avec un moyen de les personnaliser.
Proposer une séparation des rôles : les développeurs livrent le projet, un groupe d’administrateur définit les environnements et un autre groupe déploie l’application, etc.
Supporter une charge croissante d’environnements avec plusieurs applications et de nombreux utilisateurs.
Être capable de faire des déploiements multi-plateformes : des environnements complexes peuvent s’étendre sur de multiples systèmes d’opération et versions.

Les outils d’automatisation de packaging ne répondent pas à ces pré-requis et vouloir les étendre ne fera que complexifier leur utilisation sans pour autant faciliter convenablement les déploiements.
Cela explique l’émergence d’outils de déploiement automatique, qui ont dépassé les anciens outils de scripts « maison ».

Que l’on soit bien d’accord, les outils de déploiement automatique ne remplacent pas les outils d’automatisation des packages. Mais les deux ont leur place dans le paysage des livraisons d’applications. Les outils de packaging produisent le code exécutable et les outils de déploiements s’assurent de rendre ce code disponible pour les utilisateurs finaux !

Dans le prochain article de cette série, nous expliquerons en quoi le déploiement automatique est différent du mécanisme de gestion des livraisons de nouvelles versions.

Traduction libre du billet « Deployment automation vs. build automation » publié par Vincent Partington sur blog.xebia.com.

Revue de Presse Xebia

Xebia France — Tue, 07 Sep 2010 10:00:33 +0000

La revue de presse de l’actualité Java/J2EE hebdomadaire proposée par Xebia.

Actualité éditeurs / SSII

SOA

Lancement de vFabric au VMworld 2010 : Spring in the cloud

Le coin de la technique

Evènements de notre communauté en France et à l’étranger

Jug Summer Camp 2010 – La Rochelle

Actualité éditeurs / SSII

Cloudbees propose Hudson en Software as a Service

Le Software as a Service fait beaucoup de bruit, mais peu d’initiatives tangibles émergent. C’est peut être à cause de la complexité de nos logiciels, ou bien à cause du manque de maitrise qui en résulte, que nous hésitons à les déporter sur un environnement de type cloud. Alors, pourquoi ne pas commencer petit, avec un logiciel que nous maitrisons parfaitement ? Plutôt que d’arriver chez vos clients et de systématiquement reconstruire une plateforme d’intégration continue, Cloudbees propose Hudson « à la demande » (_HaaS_ Hudson as a Service). Avec un dimensionnement automatique du nombre d’agents nécessaires pour effectuer l’ensemble des taches de votre build, Cloubees offre une réelle parallélisation des traitements, et donc des builds plus rapides. Ant, Maven et le Jdk sont disponibles dans une grande variété de versions. Et, petit plus appréciable, Cloudbees propose « gratuitement » des repositories GIT, SVN et un dépôt Maven privés.
La facturation se décompose en deux parties :

un partie fixe, de 25$ à 35$ par mois, en fonction du nombre de user (5 ou 10).
une partie variable, par agent et par minute d’utilisation (0,6$ par heure et par agent).

Reste à sortir les calculatrices, pour savoir si dans votre cas mieux vaut mobiliser un master et plusieurs slaves Hudson dans votre propre infrastructure, ou bien si le tarif agressif de ce nouveau mode d’intégration continue vous décidera à déposer vos sources sur le cloud. Pour tester ce nouveau service, Cloudbess propose une version d’évaluation de 7 jours, incluant 7 heures de build.

JBoss met en avant les performances de HornetQ

Un peu plus d’un an après la sortie officielle d’HornetQ, sur les fondations de JBoss Messaging, RedHat tente de prouver sa maturité et son avance sur d’autres produits du marché. Un benchmark, proposé par eux-mêmes, compare les produits suivants:

HornetQ 2.1.1 final
ActiveMQ 5.3.2 GA
SwiftMQ 7.6
OpenMQ 4.4
d’autres produits mais anonymes

Les scénarios choisis suivent ces critères:

le nombre d’acteurs: d’un producteur et un consommateur (1/1) jusqu’à un scénario avec 40 acteurs de chaque côté.
la taille des messages allant de 12 bytes à 1k byte.
de type publish/subscribe ou point-à-point
la persistance ou non des messages
la persistance transactionnelle ou non

Sans trop de surprises, HornetQ s’en sort très bien au niveau des résultats, ActiveMQ trainant beaucoup la patte, même face à d’autre concurrents. Bien que forcément partial, on peut cependant dégager quelques remarques intéressantes sur les points forts de HornetQ:

le MoM devance de loin ses concurrents sur le transfert de petits messages non persistés
la différence est moins grande pour le transfert de messages non persistés plus gros (1k), et se fait parfois même dépasser
la différence est à nouveau grande dans les scénarios de persistance

HornetQ est capable d’utiliser un mode asynchrone pour l’écriture des fichiers à condition d’être sur une distribution particulière de linux. Cette option n’est pas spécifiée dans le benchmark et donc ne doit pas être utilisée, mais une précision serait la bienvenue, histoire d’être sûr.

Les benchmarks de ce type sont souvent sujet à polémiques et celui-ci en fait partie. Les scénarios sont souvent trop simples, chaque éditeur a ses options très spécifiques à tel cas d’utilisation. Néanmoins on peut lire entre les lignes les points forts et les points faibles et ensuite à chacun de se faire une opinion.

SOA

Lancement de vFabric au VMworld 2010 : Spring in the cloud

La semaine dernière, VMWare était au coeur de l’actualité avec l’évènement VMworld qui a été le théâtre de plusieurs annonces dont celle de VFabric.
VMWare souhaite pousser les applications dans le Cloud et il a rassemblé sous le nom VFabric, les différents éléments de sa plateforme pour le développement et l’exploitation d’applications cloudifiées.
L’annonce est relayée sur le blog de Rod Johnson qui nous donne sa vision de cette nouvelle plateforme. SpringSource qui s’est fait connaitre grâce au framework Spring dispose maintenant d’un portefeuille de technologies conséquent :

son serveur d’application tcServer (reposant sur Tomcat),
le datagrid GemFire,
le serveur web et le load balancer de la solution Enterprise Ready Server (basé sur le serveur web Apache),
la solution de monitoring Hyperic,
le système de messaging RabbitMQ.

Ces différentes technologies sont associées aux solutions de virtualisation de VMWare pour former leur boîte à outils du cloud computing VFabric.

VMWare et SpringSource continuent donc sur la route initiée il y a un peu plus d’un an par le rachat de SpringSource par VMware (dont nous vous parlions ici) et le rachat de CloudFoundry (ici pour plus d’informations) avec pour but que le cloud soit l’infrastructure d’exécution des applications informatiques de demain.

Le coin de la technique

GWT 2.1 sera Maven compliant

Google depuis quelques mois fait de gros efforts pour rendre leurs GWT et AppEngine plus Maven-friendly. L’arborescence assez spécifique de ces projets obligeait jusqu’à maintenant de se contenter de solutions intermédiaires. Nicolas De Loof nous annonce sur son blog l’arrivée d’une nouvelle version compatible entièrement avec la future version 2.1 de GWT. Par exemple une option -maven du script webAppCreator permettra de construire le fichier selon les conventions Maven.

Une des plus grosses difficultés provient des changements parfois assez importants d’une version à une autre de GWT. Or le plugin actuellement est maintenu de sorte qu’il soit compatible avec toutes les anciennes SDK. Nicolas De Loof propose à présent que chaque nouvelle version du plugin soit callée sur celle de GWT. Si vous êtes d’accord avec ce principe vous pouvez voter ici.

OAuth : pas le protocole d’authentification ultime ?

En 2007, suite à des réflexions sur le moyen de déléguer à des API l’accès à des ressources privées, les créateurs du site Ma.gnolia finirent par inventer OAuth, un protocole ouvert destiné à remplir cette fonction. Beaucoup ont alors cru voir arriver le protocole d’authentification ultime. Mais si la sécurité informatique était simple, cela se saurait !

Jusqu’à il y a peu, les applications clientes de Twitter se connectaient à celui-ci en demandant simplement leur mot de passe et login aux utilisateurs. Mais cela représentait un risque: rien ne dit qu’une application à laquelle on donne ses codes d’accès ne va pas les transmettre à quelqu’un de mal intentionné qui pourrait en faire mauvais usage ou tenter de réutiliser votre mot de passe sur d’autres sites (au cas ou vous feriez partie des nombreuses personnes qui réutilisent le même mot de passe pour de nombreux services, ce qui n’est bien sûr pas votre cas ). Mais récemment, Twitter a fermé son accès basic auth et oblige les applications à utiliser le protocole OAuth. Et comme le raconte Ryan Paul, le développeur du client de microblogging Gwibber sur Ars Technica cela ne va pas sans poser problème. Par exemple pour les applications standalone, les clefs requises par le protocole doivent se trouver dans le programme. Or toute donnée informatique, même bien obfusquée, peut se retrouver (avec un peu de travail ou parfois même un simple éditeur héxa !). Ainsi les clefs qui sont sensées garantir l’identité de l’application appelante ne garantissent plus rien. Ryan Paul a lui même facilement fait passer auprès de Twitter sa propre application pour le client Twitter officiel. Lorsque l’on sait que Twitter menace de désactiver certaines applications en cas d’abus ou si leur clefs sont compromises, on peut logiquement s’attendre à voir arriver des attaques visant à désactiver les applications des concurrents.

Un autre cas problématique est la position des nombreux clients Twitter Open-Source. Comment garder ses clefs secrètes tout en publiant son code source ?! Epineux problème !

Bref, il semble que la question, loin d’être simple, ne soit pas prête d’être réglée. C’est pour cela qu’elle mérite que l’on s’y intéresse de prés, au travers du long article de Ryan Paul qui passe en revue les différents problèmes, dont certains spécifiques à l’implémentation OAuth de Twitter. Et dans l’état actuel des choses, cette dernière semble plus destiné à permettre les interactions de serveur (client) à serveur (Twitter) plûtot que d’application standalone à serveur (Twitter).

Ruby on Rails 3 est sorti du bois, JRuby l’attendait au bar

Avis au amateurs de Ruby et de JRuby ! Le célèbre framework web le plus productif au monde est sorti dans sa version 3.0. La communauté Ruby vibre déjà et les observateurs externes se demandent si le buzz va devenir aussi gros que lors de la sortie de la 1.0 en 2006. Parmi les nouveautés, on peut citer :

intégration d’un nouveau moteur de génération de requêtes SQL : ARel.
refonte du moteur de routing url -> contrôleur pour une approche plus REST.
refonte des entrailles pour passer d’un code monolithique à du tout modulaire.
nouvelle API de plugins

Le point important pour nous autre du monde Java, c’est que l’équipe JRuby a travaillé, en parallèle de Rails, à intégrer toutes les nouveautés. JRuby 1.5 supporte Rails 3 depuis sa version bêta de février, mais pour l’instant il n’y a que peu de retours JRuby + Rails 3.0, donc si le coeur vous en dit, testez et remontez du feedback.

L’annonce officielle

Evènements de notre communauté en France et à l’étranger

Jug Summer Camp 2010 – La Rochelle

Le 10 Septembre aura lieu à la Rochelle le Jug Summer Camp. Il s’agit de la conférence Java de la rentrée qui s’étale sur toute la journée du vendredi.
Le programme est bien fourni, et les sujets tourneront principalement autour de Java EE 6 (avec GlassFish, JPA 2, JSF 2 …) et n’oublions pas Maven 3 avec Nicolas De Loof et Spring 3 avec Julien Dubois. Le planning est disponible ici et les inscriptions sont maintenant closes. Vous n’avez pas pu vous inscrire mais vous voulez quand même savoir ce qui s’est passé ? Alors pensez au blog des Duchess France qui seront présentes durant cette journée et couvriront l’évènement. Merci à Orianne Tisseuil et Jérôme Petit, JUG Leader du Poitou Charentes JUG, pour l’organisation de cet évènement.

Revue de Presse Xebia

Xebia France — Tue, 01 Jun 2010 05:36:54 +0000

La revue de presse de l’actualité Java/J2EE hebdomadaire proposée par Xebia.

Actualité éditeurs / SSII

Où sont passées les stars de Sun ?

Le coin de la technique

Actualité éditeurs / SSII

Où sont passées les stars de Sun ?

Un an après le rachat de Sun par Oracle, qu’est il advenu des stars de Sun ? La réponse est plutôt radicale : elles se sont envolées vers des cieux plus cléments. Avant d’entrer dans plus de détails, on peut d’abord noter que la différence « génétique » entre Sun, moteur d’innovation proche d’une entreprise de recherche, et Oracle, éditeur logiciel centré sur le business, augurait de nombreux chocs culturels.
Certains ont été violents, et la rupture a été amère. C’est le cas pour James Gosling, qui a été le plus prolixe (sur son blog) au sujet de son départ, évoquant une démission qui l’a occupé à plein temps pendant plusieurs semaines. De manière comparable, Tim Bray a rejoint Google, en ne détaillant pas les raisons qui l’ont poussées à quitter Oracle mais en laissant transparaître une certaine amertume.
D’autres sont partis car Oracle ne leur donnait pas de garanties sur leur technologie : Charles Nutter et Thomas Enebo ont rejoint Engine Yard pour continuer à développer JRuby. Kohsuke Kawaguchi a monté sa société pour porter Hudson.
Enfin, certains n’ont pas reçu d’offre d’Oracle. C’était attendu pour Jonathan Schwartz et Scott McNealy qui étaient quasiment condamnés par leur position au sommet de la hiérarchie de Sun. C’était plus surprenant pour Simon Phipps, responsable de l’open source, qui occupe un poste équivalent chez ForgeRock (qui entend développer -OpenSSO- pardon OpenAM, le nom OpenSSO étant déposé).
Alors, cette vague de départs sera t’elle préjudiciable à Oracle ? Sur le plan de l’innovation, certainement. Sur un plan purement business, on peut en douter, aucun des « sous »-produits (sans que nous portions de jugement de qualité) de Sun n’étant stratégiques pour la firme de Larry Ellison. D’ailleurs, si l’on jette rapidement un œil à ceux qui sont restés, on note John Fowler, Cindy Reese, et Mike Splain, tous trois impliqués dans la branche hardware. De là à dire que c’était la principale visée d’Oracle (avec la JVM)… « Malheureusement », Oracle a aussi hérité de bébés bien encombrants, comme les JUG (voir l’article de Nicolas de Loof à ce sujet).

Via infoWorld

Le coin de la technique

Nouvelle version pour EhCache

Terracotta maintient le rythme des évolutions Ehcache, en nous livrant cette nouvelle version numérotée 2.1.
Après un mois de maturation en bêta, l’éditeur officialise donc la dernière mouture stable de son célèbre cache.
C’est surtout l’occasion d’étoffer son offre produit en ajoutant notamment un plugin de monitoring permettant de surveiller en temps réel les métriques essentielles du cache. Grâce à lui, les développeurs pourront affiner la configuration du cache, par contre pour l’utiliser en production il vous faudra une version payante.
Le support Websphere a bénéficié lui aussi d’améliorations pour garantir à ses utilisateurs l’accès à toutes les fonctionnalités du produit.
Cela inclut tout naturellement, le support la solution Terracotta Web Session, un cluster de session web à haute disponibilité, déjà disponible pour Weblogic, JBoss, Tomcat et Jetty.
L’utilisation de JTA a aussi été largement améliorée, les configurations standalone et Hibernate sont à présent supportées, ce qui permet de couvrir l’intégralité des stratégies Hibernate.
En dernier point d’amélioration, le développement a été axé vers de meilleures performances et un paramétrage fin des SLAs. C’est par exemple la fonctionnalité NonStopCache qui permet de contrôler le timeout des opérations sur le cache, voire même de passer automatiquement d’un cache sur disque à un cache en mémoire vive en cas d’indisponibilité. Par ailleurs le UnlockedReadsView offre une vue non consistante du cache. Dans les faits, elle ignore les verrous d’écriture et ne pose pas de verrou de lecture, l’équivalent d’un READ_UNCOMITTED avec des performances très largement accrues.

jucProfiler

Il y a quelques années, certains se sont arrachés les cheveux pour détecter les contentions dans un programme massivement parallélisé. Malheureusement pour les amoureux des nœuds au cerveau, les développeurs de chez IBM se sont penchés sur le sujet et proposent un outil pour diagnostiquer ce type de problèmes : jucProfiler (pour java.util.concurrent). Le principe est simple : instrumenter le bytecode de certaines classes de java.util.concurrent.locks et tracer les appels à java.util.concurrent.locks.LockSupport et java.util.concurrent.locks.AbstractQueuedSynchronizer.
L’outil génère ensuite un rapport permettant d’identifier deux types de problèmes sur les thread, consomateurs de temps :

du temps de contention : un verrou est réservé par un autre thread.
du temps d’attente : le thread est en wait.

Et cerise sur le gâteau, pour ceux d’entre vous lassés de devoir diagnostiquer des problèmes de performances en analysant des fichiers texte de trois pieds de long, un éditeur graphique est même fourni.

Comme le dit justement la conclusion de l’article, la généralisation de la programmation parallèle nous oblige à nous armer de meilleurs outils. Il semblerait que jucProfiler en fasse partie. Si l’un de nos lecteurs a eu l’opportunité de l’utiliser en condition réelle, nous sommes bien sûr preneurs d’un retour d’expérience.

Maven Enforcer

Sonatype a récemment mis en ligne une présentation en deux parties (ici et là) sur le plugin Maven Enforcer.
Ce plugin permet de définir des règles afin d’obtenir un build Maven reproductible sur différents environnements. Il permet entre autres :

de spécifier une version ou une plage de versions de Maven,
de spécifier une version ou une plage de versions du JDK,
de spécifier une architecture (OS/CPU) sur laquelle s’exécute le build,
de s’assurer que le projet ne contient pas de dépendances (transitives) vers des versions non explicites (SNAPSHOT, LATEST ou RELEASE),
de s’assurer que le projet n’utilise pas de plugins ayant une version non explicite (SNAPSHOT, LATEST ou RELEASE),
de bannir des dépendances,
de définir ses propres règles (en Java ou avec un script BeanShell).

La présentation met l’accent sur la nécessité de fixer les versions des dépendances et des plugins afin d’éviter qu’un build ne devienne instable suite à la publication d’une nouvelle version d’une dépendance ou d’un plugin. Il préconise notamment l’emploi de Maven en version supérieure à 2.0.9 pour laquelle le POM parent n’utilise plus que des versions explicites des plugins.

Elle recommande aussi de spécifier une version du JDK (1.5.x par exemple) afin d’éviter différentes problématiques telles que l’utilisation d’API non supportées ou la différence de comportement de certains plugins Maven en fonction de la version de la JVM sur laquelle ils sont exécutés.

Une fois les bonnes pratiques exposées, la configuration des différentes règles permettant d’effectuer les vérifications est abordée.

Le plugin Maven Enforcer est encore peu connu mais gagnerait à être utilisé pour éviter des problèmes récurrents. Cette présentation est un bon point de départ pour aborder sa mise en place.

SBT (simple-build-tool) pour Scala

Romain Maton — Thu, 06 May 2010 07:53:40 +0000

Maintenant que vous êtes tous convaincus par Scala, nous allons regarder durant les prochaines semaines quelques outils et frameworks indispensables pour démarrer nos projets d’entreprise. En effet, tout comme dans nos projets Java, il n’est plus envisageable au jour d’aujourd’hui de commencer un projet sans un environnement minimum : un bon IDE, un outil de build, de l’intégration continue, un outil de couverture de tests et bien d’autres. Leurs buts : nous faciliter le développement et nous avertir d’éventuels problèmes dans notre code (manque de tests, trop de warnings…).

Le sujet de cet article n’est autre que le framework Scala qui monte (très vite) en ce moment à savoir sbt (pour simple-build-tool). Nous verrons dans cet article ce qu’est sbt, ses différentes fonctionnalités et en quoi cet outil va nous être très utile dans nos développements quotidiens.

Yet Another Build Tool ?

sbt est un outil de build qui se veut simple d’utilisation. Son objectif est de fournir des fonctionnalités basiques et avancées très simples à implémenter sur un projet Scala ou Java.
On pourra dès lors n’utiliser notre IDE qu’en tant qu’éditeur de texte et laisser à sbt les tâches de compilation, de tests unitaires sur une ou plusieurs versions de Scala (très utile pour les concepteurs d’API), changer de version de Scala en cours de développement…

La configuration de se fait en Scala à l’aide d’un DSL qui vous permettra de spécifier ses dépendances de projet, ses plugins et beaucoup d’autres paramètres. Le gestionnaire de dépendances utilisé est ivy. Il est possible pour son projet de spécifier un repository maven ou autre et ainsi n’avoir qu’un seul repository centralisé sur sa machine.

A notez que sbt tourne au minimum sur Java 5.

Fonctionnalités

Générales

L’outil propose plusieurs fonctionnalités en standard dont :

Configuration du projet en Scala,
Compilations et tests en continu,
Support de projets Java et Scala,
Génération de la scaladoc,
Frameworks ScalaCheck, Specs et ScalaTest supportés par défaut,
Démarrage du REPL avec projet et dépendances dans le classpath,
Exécution de tâches en parallèle (dont les tests),
Gestion de dépendances inline, ivy ou maven.

Nous allons regarder plus en détail les actions possibles dans sbt, la configuration d’un projet sbt ainsi que les quelques cas d’utilisation.

Actions

Il y a plusieurs manières d’utiliser sbt. Soit en lançant la console sbt pour effectuer nos actions unitairement dans l’environnement sbt, soit en mode batch avec certaines commandes prédéfinies dans l’appel à sbt. Il est aussi possible (nous le détaillerons plus tard dans l’article) de mettre une action en attente de modification de fichiers pour ensuite être lancée.

// Console
$ sbt
> compile
> test
> ...
// Batch
$ sbt clean compile "get sbt.version"
// Wait
$ sbt
> ~ test

Il est possible de lancer une action sur une version de Scala spécifique. Ainsi, si l’on souhaite par exemple compiler notre projet en Scala 2.8.0 alors que notre projet est actuellement en Scala 2.7.7, nous ferons :

// 2.7.7 by default
> compile
// Force 2.8.0.Beta1 version
> ++2.8.0.Beta1 compile

Les actions possibles sont assez nombreuses sachant que vous connaissez déjà bon nombre d’entre elles :

clean, compile, exec, jetty-run, package, test… qui font ce que vous savez ,
update pour mettre à jour vos dépendances,
sh qui invoque le shell unix pour par exemple exécuter un find,
nombreuses actions sur test-* et package-* avec plusieurs déclinaisons (all, docs, project, failed, quick...),
console et console-quick pour démarrer l’interpréteur Scala (REPL), la différence entre les deux se faisant sur le classpath chargé au démarrage,

Concernant les actions qui touchent à l’environnement sbt, nous avons :

exit, quit, help, info, debug, trace, warn, error…,
reload qui permet de recharger les modifications effectuées sur la configuration de notre projet,
current qui nous donne le nom du projet ainsi que le niveau de log actuel,
projects qui liste tous les projets disponibles en cas d’arborescence de projets,
; A ; B qui exécute une action A et qui, si elle réussie, exécute une action B.

Il est bien sûr possible de créer ses propres actions en construisant une tâche Task de la manière suivante :

lazy val foo = task { log.info("Foo !"); None }

La tâche foo sera alors créée et disponible dans la console sbt. A noter qu’une syntaxe minuscule et une séparation par tiret est respectée pour les noms de tâche, ainsi une variable nommée fooBar donnera comme tâche foo-bar.

Il est possible de définir sur quelle phase du build la tâche doit être lancée et de fournir une description de la tâche :

lazy val jars = task { ... } dependsOn(compile, doc) describedAs("Package classes and API docs.")

Il est aussi possible de modifier des actions existantes comme clean, test ou bien encore package mais aussi de modifier la dépendance de ces tâches par rapport à d’autres tâches. Vous pouvez aussi faire de l’exécution conditionnelle pour des tâches générant des fichiers. Différentes stratégies existent, on pourra ainsi définir qu’une tâche ne doit être exécutée que si les fichiers cibles qu’elle génère sont périmés ou bien constamment générer ces fichiers cibles.

Configuration

L’arborescence d’un projet sbt est la suivante :

lib/
lib_managed/
project/
   boot/
   build/
      MyProjectConf.scala
   plugins/
      Plugins.scala
   build.properties
src/
   main/
      scala/
      resources/
   test/
      scala/
      resources/
target/

On remarque la même arborescence de dossier que pour un projet maven à savoir src/main/scala et src/main/resources pour les sources et src/test/scala et src/test/resources pour les tests. Concernant les autres dossiers, lib vous permettra de déposer vos librairies, lib_managed contiendra vos dépendances (si aucun repository n’est spécifié), project/build votre configuration projet tandis que project/plugins vous permettra de définir les plugins que votre projet utilisera.

La définition des dépendances et la gestion des plugins se fait en Scala. Voici quelques exemples de définition de dépendances :

lazy val jetty = "org.mortbay.jetty" % "jetty" % "6.1.22"
lazy val h2 = "com.h2database" % "h2" % "1.2.121"
lazy val junit = "junit" % "junit" % "4.5" % "test"
lazy val slf4 = "org.slf4j" % "slf4j-log4j12" % "1.4.1"

Il est possible de définir un projet de type parent qui contiendra plusieurs projets (modules). La configuration pour ce type de projet est la suivante :

import sbt._
class ParentProject(info: ProjectInfo) extends ParentProject(info) {
   lazy val core = project("core", "Core project")
   lazy val client = project("client", "Client project", core) // Project based on core
   lazy val dao = project("dao", "DAO project", new DAOProject(_))
   class DAOProject(info: ProjectInfo) extends DefaultProject(info) {
      // Define here custom dependencies
   }
}

Il est aussi possible de définir sa configuration projet à partir d’un fichier maven pom.xml ou d’un fichier ivy ivy.xml. Pour cela, il suffit de les ajouter à la racine de votre projet. Ainsi, sur une commande update, sbt utilisera le fichier maven ou ivy pour gérer les dépendances du projet.

Les configurations possibles sont nombreuses. Pour une configuration plus avancée, je vous renvoie vers cette page qui détaille exhaustivement tout ce que l’on peut faire en terme de configuration dans un projet sbt, du changement de l’arborescence des dossiers aux options de compilation, package et test.

Cas d’utilisation

Triggered execution

En effet, sbt ne se résume pas qu’à un simple outil de configuration projet. Nous avons vu au début de cet article les actions possibles dans sbt, comme par exemple compile ou test. Ce sont des actions one shot qu’il faudra relancer autant de fois que l’on voudra pour, dans ce cas, compiler ou tester.

Mais, en préfixant ces actions par le caractère ~, sbt se mettra en attente de modification dans le scope de l’action et dès qu’une modification sera effectuée, l’action sera déclenchée, d’où leur nom : triggered execution. Ainsi, si une modification se produit par exemple dans src/main/scala, compile et test seront appelés car ils sont en attente de modifications sur les fichiers sources du projet.

Actuellement, trois types d’actions sont de type triggered execution :

compilation : avec la compilation continue par ~ test-compile ou uniquement la compilation des sources dans main avec ~ compile ;
test : avec ~ test-quick pour lancer les tests qui n’ont pas encore réussi (nouveau ou failed du tests précédent) ou qui ont été recompilés, ~ test-failed pour lancer uniquement les tests qui n’ont pas encore réussi (mais ne relance pas les tests recompilés comme ~ test-quick) et ~ test-only mytestpackage.MyTest pour lancer les tests de la classe spécifiée ;
web-app : si vous utilisez jetty et une fois jetty lancé (jetty-run), la commande ~ prepare-webapp recompilera la webapp pour prendre en compte les modifications. Pour avoir une compilation continue totale, je vous renvoie à la section JRebel qui explique comment prendre en compte JRebel pour scanner certains dossiers à recharger dynamiquement et ainsi éviter les reloads de Jetty.

Cross building

L’autre cas d’utilisation qu’offre sbt est le cross building. Cette fonctionnalité est un véritable atout pour toute API ayant comme cible de nombreuses versions de Scala, surtout si elles ne sont pas binairement compatibles entre elles, comme par exemple Scala 2.7.7 et la prochaine version 2.8.0 (mais c’est aussi le cas entre 2.7.2 et 2.7.4).

Voyons d’abord comment utiliser une librairie packagée différemment pour cette version de Scala. L’exemple ci-dessous montre en premier le fait d’imposer la version de Scala. Le problème est que si l’on change temporairement de version de Scala dans notre projet, il risque de ne pas builder. Le second exemple nous montre que sbt peut récupérer la bonne version de la librairie en fonction de la version de Scala courante de notre projet à l’aide de la dépendance spéciale %% :

val dispatch = "net.databinder.dispatch" % "dispatch_2.7.7" % "0.7.2"
val dispatch = "net.databinder.dispatch" %% "dispatch" % "0.7.2"

Maintenant, nous allons pouvoir construire notre projet dans différentes versions de Scala en très peu de configuration et surtout en un caractère ! La définition se fait directement dans la console sbt de la manière suivante :

$ sbt
> set build.scala.versions 2.7.7 2.8.0.Beta1 2.7.5 2.7.3 2.7.2
> reload

Par défaut, sbt utilisera la première version définie comme version par défaut. Vous pouvez bien sûr changer de version à tout moment à l’aide de la commande ++version.

Et pour le cross building, il suffit de préfixer notre action par + pour qu’elle soit exécutée sur toutes les versions ciblées par notre projet :

> +package
> +publish

Point important : certaines dépendances de votre projet ne seront peut-être pas les mêmes selon les versions de Scala que vous ciblez. Il est donc important de faire un pattern matching sur les API qui pourraient poser problème :

val scalatest = buildScalaVersion match {
   case "2.7.5" => "org.scala-tools.testing" % "scalatest" % "0.9.5"
   case "2.7.2" => "org.scalatest" % "scalatest" % "0.9.3"
   case x => error("Unsupported Scala version " + x)
}

Project console

Dernier cas d’utilisation que nous verrons dans cet article, le lancement de la console avec tout le contexte de projet intégralement chargé. Ainsi, console-project démarre l’interpréteur Scala avec le projet courant chargé. On peut dès lors utiliser tous nos objets et faire quelques tests directement dans la console.
Mais ce mode permet bien plus que l’appel de nos objets, il permet aussi, entre autres, de :

voir les options de compilation : compileOptions.foreach(println) ;
voir tous les repository : repositories.foreach(println) et ivyRepositories.foreach(println) ;
voir le classpath de compilation et celui des test : compileClasspath et testClasspath ;
ou bien encore voir les dépendances de projet : mainDependencies.external, mainDependencies.libraries et mainDependencies.scalaJars.

Installation

Maintenant que vous en savez plus sur sbt, j’espère que vous avez l’eau à la bouche et que avez envie de jouer avec l’outil Nous allons donc voir comment installer la bête. Tout d’abord, rendez-vous sur cette page pour télécharger la dernière version de sbt.

Pour l’installation sous Mac, il suffit d’ajouter un fichier dont le nom sera sbt au même niveau que votre Jar sbt avec le contenu suivant :

java -Xmx512M -jar `dirname $0`/sbt-launch.jar "$@"

Il faudra ensuite ajouter dans votre path le répertoire contenant ce fichier et le Jar sbt. Exemple dans .bash_profile :

export SBT_HOME=$HOME/dev/scala/sbt
export PATH=$SBT_HOME:$PATH

Voilà, c’est installé ! Pour les accros de la ligne de commande, voici un mode d’installation fait pour eux (unix) qui est d’ailleurs expliqué sur le site de sbt qui installe sbt dans /usr/local/bin/ :

$ cd ~
$ wget http://simple-build-tool.googlecode.com/files/sbt-launcher-0.7.3.jar
$ sudo mv sbt-launcher-0.5.6.jar /usr/local/bin/sbt-launcher.jar
$ echo "java -Xmx512M -jar /usr/local/bin/sbt-launcher.jar "$@"" | sudo tee /usr/local/bin/sbt
$ sudo chmod +x /usr/local/bin/sbt

En ce qui concerne l’installation Windows, cela se passe ici.

Nous allons maintenant tester l’installation. Commençons par créer un dossier, déplaçons nous dedans et lançons la commande sbt en répondant s à la question de création de projet (pour scratch qui fera une configuration rapide du projet). Faisons ensuite un compile même si aucune source n’existe actuellement :

$ mkdir foobar-project
$ cd foobar-project
$ sbt

Build successful ! Ajoutons maintenant un fichier PrintMessage.scala dans src/main/scala qui affichera un message dans la console sur la tâche run :

object PrintMessage {
  def main(args: Array[String]) = println("Foobar Scala !")
}

Et maintenant lançons notre message à l’aide de l’action run :

$ sbt run

Vous voilà prêt pour utiliser sbt !

Conclusion

Cet outil est déjà très utilisé par plusieurs projets Scala open-source (dont par exemple akka). Les possibilités sont très nombreuses et n’ont pas toutes été énumérées dans le présent article. Je vous renvoie vers le wiki de sbt pour un détail complet des fonctionnalités de l’outil.

Ce qui ressort après quelques heures d’utilisation c’est l’extrême simplicité d’utilisation de l’outil, la simplicité de configuration d’un projet et la puissance d’avoir en tâche de fond les tests en continu. Certaines personnes vont même jusqu’à se désynchroniser totalement de leur IDE qui ne devient dès lors qu’un simple éditeur de texte laissant à sbt la compilation, les tests et l’exécution. D’autres nous expliquent comment configurer Eclipse pour faire du debug sur des tests lancés depuis la console sbt.

Un petit exemple de projet sbt est d’ailleurs disponible sur mon GitHub. A vous de jouer !

Premiers pas avec GreenPepper XWiki

Nathaniel Richand — Fri, 09 Apr 2010 07:44:49 +0000

Adepte de longue date de Fitnesse, j’ai toujours aimé l’aspect collaboratif du wiki permettant de sortir les tests du code et de les exposer à d’autres populations moins technique. Cependant, malgré le succès du projet et la grande communauté qui l’entoure, Fitnesse reste compliqué à mettre en place et certaines fonctionnalités de bases font cruellement défaut. De plus, le passage de Fit à Slim a fortement contribué à complexifier le projet.
Pour moi, Fitnesse est un projet passionnant et porteur de nombreuses innovations. Cependant, l’absence de structuration et le manque de documentation le rend très difficile à mettre en oeuvre et demande une réelle expérience. Je vous conseille tout de même de garder un oeil sur celui-ci, car, depuis l’année dernière, le projet est redevenu très dynamique (pas moins de sept releases) et semble gagner en maturité (je vous conseille notamment cet article sur les nouveautés).

J’ai plusieurs fois dans le passé eu l’occasion de voir des présentations de GreenPepper par les équipes de Pyxis. GreenPepper partage le même concept que Fit/Fitnesse mais a fait le choix de s’appuyer sur un Wiki existant robuste et mature : Confluence. Ce choix est un des gros atouts de GreenPepper, mais c’est aussi la raison qui m’a toujours fait écarter cette alternative. En effet, j’ai toujours trouvé difficile de promouvoir un logiciel en expliquant qu’il faudrait non pas acheter une mais deux licences (pour les entreprises non équipées en Confluence) et qu’il faudrait configurer et maintenir les deux logiciels.

Cependant, ce point de blocage a été adressé lors de la version 2.6 sortie en novembre 2009, qui permet désormais de pouvoir faire reposer GreenPepper sur XWiki qui est gratuit et open source.

Je vous propose donc de m’accompagner dans le test de cette nouvelle version au travers de cet article qui aborde :

l’installation de GreenPepper et la configuration de XWiki,
la création des premiers tests,
la configuration de Maven et Eclipse pour GreenPepper,
la création des fixtures,
un petit retour d’expérience,
mes espoirs pour le futur.

Avant de vous lancer dans la lecture de cet article, notez que celui-ci est purement technique et nullement philosophique. La présentation de l’ATDD (Acceptance Test Driven Development) ne sera pas abordée ici.

Installation de GreenPepper et configuration de XWiki

Pour ce test, je suis parti sur la version Standalone avec Jetty et HsqlDB embarqués. Téléchargement, unzip, start_xwiki.bat, c’est parti!

Je me connecte avec un login d’administrateur pour configurer GreenPepper (par défaut Admin/admin). Il faut noter qu’il n’y a pas de groupe de droits dédié pour GreenPepper, uniquement le groupe « greenpepper-users » destiné à identifier les utilisateurs autorisés pour la version avec licence.

Pour les besoins de ce test, je saisis un numéro de licence d’essai.

Puis je me crée un nouvel espace qui va accueillir les tests de mon application. Ici, un batch créé précédemment pour les besoins d’un XKE :

Et je définis mon espace comme un projet GreenPepper :

Création des premiers tests

Le wiki étant prêt, je peux passer à l’écriture de mes premiers tests. Pour cela, je commence par créer une page pour accueillir mon test :

Premier test

Pour mon premier test je vais tester le format do with qui correspond à un flow, voici mon test en format wiki :

|= import| fr.xebia.batch.fixture
Ce test va simplement lancer mon batch et m'afficher en couleur le résultat d'exécution :
|= do with|=xebian
|lancer le batch

Cependant, il est très agréable également d’utiliser l’éditeur WYSIWYG. Celui-ci fera plaisir au gens du métier qui n’aime en général pas trop la syntaxe Wiki :

Il existe des compléments dans fitnesse tels RichNesse pour avoir un éditeur graphique, mais cette alternative était assez buggée lors de ma dernière utilisation…

Second test

Pour ce deuxième test je vais essayer le format scenario. Ce format est assez révolutionnaire, et permet d’écrire une spécification de manière naturelle sans devoir découper dans un tableau le passage de variables. Pour récupérer dans le code les variables, on procèdera par des expressions régulières (voir plus bas).

{{greenpepper-import parameter="fr.xebia.batch.fixture"/}}
|= Scenario |= XebianScenario
|= lancer le batch xebia avec le fichier toto.xml
|= vérifier que les 2 affaires ont été créées

Les variables qu’il nous faudra récupérer sont « xebia », « toto.xml » et « 2″. A noter que j’ai utilisé ici la macro import. Son intérêt est de masquer le tableau contenant les imports de package. Ainsi notre page ne contient que des données métiers et aucune donnée technique :

Organisation des tests

Lorsque nous avons plusieurs tests, nous voulons pouvoir exécuter tous nos tests en un seul clic, ou bien tous les tests correspondants à une story donnée. Sous GreenPepper, on retrouve la notion de Suite existant dans Fitnesse. Pour faire ceci, j’ai trouvé deux macros différentes. Soit la macro children greenpepper-children expanded="true"/ qui va récupérer toutes les pages GreenPepper filles, soit la macro labels qui va récupérer toutes les pages d’un tag donné, par exemple : {{greenpepper-labels spaceKey="GreenPepper Batch" title="Batch" labels="Batch" expanded="true" openInSameWindow="true"/}}. Voici ce que donne nos deux macros :

Configuration de Maven et Eclipse

Configurer un projet java simple sous GreenPepper est trivial (tout comme sous Fitnesse). Il suffit d’utiliser le runner Java et de définir le chemin vers les jars que l’on teste, notre SUT (System Under Test), ainsi que le chemin vers nos fixtures (nos tests qui vont appeler notre SUT).

Maven

Le challenge pour moi, était de voir comment se comportait GreenPepper avec Maven. J’avais été très déçu par Fitnesse qui a pendant très longtemps dénigré Maven malgré sa popularité. S’il existe beaucoup de solutions pour intégrer Maven à Fitnesse, aucune ne fonctionne vraiment. Après m’être arraché les cheveux, j’avoue avoir fini par me faire ma propre solution ‘bancale’.

Pour intégrer Maven à GreenPepper, j’ai au final dû passer deux heures maximum (en me faisant aider par le forum cependant). A noter que l’intégration de Maven n’est pas parfaite, mais elle a le mérite d’être fonctionnelle. Elle se contente de chercher les définie dans le pom.xml.

Procédure d’installation (voir également la documentation) :

Copiez le jar du runner maven (à télécharger) dans le répertoire : greenpepper/maven/runner

Ajoutez un nouveau Runner :

Command Line :

java -mx252m -cp ${classpaths} ${mainClass} ${inputPath} ${outputPath} -l ${locale} -r ${repository} -f ${fixtureFactory} --xml --pdd ${projectDependencyDescriptor}

Main class : com.greenpepper.maven.runner.Main
Environment : Java

Ajoutez dans la partie classpath le runner maven ainsi que les jar de maven embedded :

greenpepper/maven/runner/greenpepper-maven-runner-2.7-complete.jar
C:\apache-maven-2.2.1\lib\maven-2.2.1-uber.jar
C:\apache-maven-2.2.1\boot\classworlds-1.1.jar

Ensuite, définissez votre SUT en renseignant le nouveau Runner Maven ainsi que le chemin vers le pom.xml (Project dependency descriptor) :

Attention 1 : Il ne faut pas renseigner les champs « System under test classpaths » et « fixture classpaths » qui rentrent en conflit avec la définition du pom.xml.
Attention 2 : De part l’utilisation de maven embedded, le fichier settings.xml de maven n’est pas utilisé. Il faut donc placer son dépôt local dans le répertoire par défaut (user/.m2/repository). Si cela vous pose problème, suivez l’évolution de la JIRA associée.

Et voilà, tout fonctionne correctement

Eclipse

Autre déception pour moi avec Fitnesse, son manque d’intégration avec nos IDE. Il existe quelques embryons de projets d’intégration de Fitnesse et Eclipse, mais je n’ai jamais réussi à avoir quelque chose qui soit véritablement fonctionnel …

Voici ma procédure avec GreenPepper :

Installer le plugin depuis l’update site : http://www.greenpeppersoftware.com/greenpepper-eclipse

Configurer le plugin, dans windows => preferences :

Server’s context path : http://localhost:8080/xwiki/greenpepper/xmlrpc
Server’s XML RPC handler : greenpepper1

GreenPepperiser le projet depuis le menu « GreenPepper ».

Configurer le SUT dans les paramètres du projet (project->properties->GreenPepper).

Il y a beaucoup d’options, j’ai juste sélectionné dans la liste mon projet, mon SUT et renseigné un lien vers mon runner (C:\greenpepper-xwiki-enterprise-jetty-hsqldb-2.7\greenpepper\java\runner).

Après avoir fait ceci, mes tests remontent directement sous Eclipse et sont exécutables :

Création des fixtures

Après avoir écrit nos tests, il faut maintenant faire le lien avec le code que l’on souhaite tester en créant des fixtures.

Test 1 (Do with):

Cette fixture, va être appelée par notre premier test défini plus tôt.

public class XebianFixture {
    public boolean lancerLeBatch(){
	//Exécute mon batch
	return "COMPLETED".equals(monBatch.getExitCode());
    }
 }

Test 2 (Scenario):

Rajouter la dépendance vers GreenPepper dans le projet de fixtures pour avoir les annotations :


      greenpepper-open
      greenpepper-core
      2.7
  
   
      
	  GreenPepper
	  GreenPepper
	  http://www.greenpeppersoftware.com/nexus/content/groups/public

Puis faire le lien avec notre code à tester :

public class XebianScenarioFixture {
	int resultingAffaire;
	@Given("lancer le batch (\\w+) avec le fichier (\\w+\\.xml)")
	public void launch(String batchName, String fileName){
		System.out.println(batchName);
		System.out.println(fileName);
		//Appeler notre batch et stocker le nombre d'affaire créées dans resultingAffaire
	}
	@Check("vérifier que les (\\d+) affaires ont été créées")
	public boolean verifyResult(int expectedAffaire){
		return expectedAffaire == resultingAffaire;
	}
}

On voit que le mode scénario apporte de nombreux avantages. Outre le fait de pouvoir écrire des tests de manière très naturelle, nos fixtures deviennent également beaucoup plus lisibles ! Les méthodes ne possèdent pas de noms à rallonge comme sous Fitnesse et, de plus, l’intention de la méthode est clairement exprimée par l’annotation (@Given, @When, @Then, @Check, …). Les arguments sont automatiquement mappés grâce aux expressions régulières qui restent relativement triviales à écrire. Si vous cherchez plus d’exemples, je vous propose un article sur le blog de GreenPepper. Mon seul bémol porte sur l’utilisation de l’annotation @Then que je n’ai pas encore bien compris, je lui préfère le @Check pour le moment.

Retour d’expérience

Vous aurez donc compris à la lecture de cet article que j’ai vraiment été conquis par GreenPepper. Au bout de seulement quelques heures je me sens à l’aise et pleinement prêt à l’utiliser.

Thomas, il y a un peu plus d’un an, parlait dans son article (que je vous encourage à lire) de certaines difficultés rencontrées lors de la mise en place de GreenPepper, dont notamment la documentation, Eclipse et Maven. Le produit a bien évolué depuis (3 releases en 2009) et je n’ai pas du tout rencontré ce genre de soucis. Au contraire, je trouve la documentation plutôt bonne ce qui compense l’absence de réelle communauté autour du projet (c’est exactement l’inverse avec Fitnesse).

Enfin, une note particulière sur le support : félicitations ! J’ai connu des supports payants totalement incompétents, dont je ne citerai pas les noms, qui se contentaient de vous recommander d’acheter la version supérieure. Ici, je n’ai pas déboursé un seul centime et j’ai eu des réponses pointues dans un délai variant de 10 minutes à quelques heures (et encore l’équipe de développement semble être au Canada). Un grand merci aux équipes de GreenPepper et plus particulièrement à François Denommée pour leur professionnalisme.

Futur

La version de GreenPepper sur XWiki est encore jeune (fin de l’année 2009) et certaines fonctionnalités ne sont encore présentes que dans la version confluence. On attend donc encore certaines fonctionnalités avec impatience (ce qui ne devrait pas tarder vu le dynamisme du produit).
Parmi celles-ci, j’en retiens trois particulièrement qui continueront de rendre ce produit indispensable :

la notion de « tag as implemented » : le testeur ou la personne du métier rédige le cas de test, or celui-ci n’est pas exécutable tant que le développeur n’a pas créé la fixture associée.

Ce flag permet de marquer (directement depuis Eclipse) que le test est prêt à être exécuté.

La macro historique d’exécution : cette macro permet de suivre l’évolution de l’exécution des tests dans le temps.
La macro include : qui permet d’inclure une page de test dans un autre test. Cette fonctionnalité est très intéressante notamment dans le cas où on a une page qui contient l’initialisation de données communes à plusieurs tests.

Voilà, je vous laisse maintenant avec toutes les cartes en main pour essayer. Bons tests à vous (dans les 2 sens) !

Maven et Android, comment utiliser le plugin ?

Erwan Alliaume — Tue, 23 Mar 2010 13:06:35 +0000

Si vous êtes développeur Android, vous aurez sans doute remarqué qu’aucun mécanisme ne permet de partager des ressources entre plusieurs projets. Étant l’auteur d’une petite dizaine d’applications, la gestion des ressources communes commence à devenir un véritable problème. En effet, s’il est très simple de partager du code Java par l’intermédiaire de jars, il vous est impossible de partager des images ou des layouts entre plusieurs applications. Ceci vient de la gestion même des ressources dans un projet Android et de leur utilisation. En effet chaque ressource est référencée sous la forme d’une constante dans un fichier ‘R.java’ automatiquement généré. C’est cette constante que vous devez utiliser pour utiliser vos différentes ressources dans vos applications. Comme il n’est pas possible d’inclure un projet Android dans un autre, nous somme bloqués.

Étonnamment, ce besoin ne semble pas intéresser plus que cela la communauté Android. En consultant la liste des demandes d’évolutions, seule une fiche fait référence à ce type de besoin. Cette demande me paraissant pourtant légitime, j’en ai discuté avec Romain Guy, l’un des développeurs Android. Selon lui, la plateforme Android ne permet pas de répondre directement à cette problématique. Tournons-nous donc vers nos outils de builds.

Cet article présente une manière de configurer un build Maven sur une application Android. Après la lecture de cet article, vous saurez comment construire et déployer un projet Android en utilisant Maven, mais également comment découper vos applications pour partager du code entre votre application Android et sa partie serveur, et comment partager du code et des ressources entre différentes applications Android. Le contenu de cet article est largement inspiré de la traduction officielle du chapitre Android du Maven Reference Guide que je viens tout juste de terminer.

Le plugin Maven Android

Le plugin Maven Android permet de construire, déployer et publier des applications Android avec Maven. Vous pouvez ainsi tirer parti des fonctionnalités Maven dans une application Android. Voyons comment utiliser un projet multi-module et la gestion des dépendances pour arriver d’une part à factoriser du code entre l’application Android et ses services web côté serveur, d’autre part à externaliser les assets/ressources communs entre plusieurs projets Android.

Pour installer ce plugin, récupérez-les sources du projet sur google code et installez les artefacts dans votre dépôt :

git clone git://github.com/jayway/maven-android-plugin.git
cd maven-android-plugin
mvn clean install

Préparez votre environnement Android pour Maven

Avant de pouvoir utiliser Maven pour construire vos applications Android, quelques tâches préalables sont nécessaires :

Installation du SDK Android
Installation des jars de l’API Android dans un dépôt (local et/ou distant)
Configuration de Maven pour simplifier l’utilisation du Maven Android Plugin

Installation du SDK Android

Le plugin Android Maven nécessite la présence du SDK Android dans votre environnement de développement. La variable d’environnement ANDROID_HOME doit être configurée pour pointer vers le répertoire d’installation du SDK Android. Ce SDK doit être installé en suivant les consignes disponibles sur le site officiel Android Developer.

En plus du SDK, vous devez également installer les différentes versions des plates-formes dont vous avez besoin pour votre développement. Il s’agit des différentes versions des runtimes Android dont vous désirez vous servir. Par défaut, vous pouvez choisir de toutes les télécharger. Pour en savoir plus à ce sujet, rendez-vous également sur la documentation officielle.

Enfin, afin de faciliter l’utilisation des outils du SDK en ligne de commande, vous pouvez rajouter le répertoire ANDROID_HOME/tools à votre PATH.

Installation des artefacts Android dans votre dépôt

Une fois que le SDK est installé, vous devez mettre à disposition les différents JARs d’API dans un dépôt Maven. L’outil Maven Android SDK Deployer permet d’effectuer cette tâche. Une fois l’outil téléchargé, rendez vous dans son répertoire et tapez la commande mvn clean install. Par défaut, cette commande installe les JARs android.jar et maps.jar dans votre dépôt local. Cet outil vous permet de n’installer qu’une partie des plateformes dans votre dépôt ou de les déployer dans sur un serveur distant, si ces fonctionnalités vous intéressent, rendez-vous à l’adresse suivante

Configuration de Maven pour Android

Afin de pouvoir utiliser les goals du plugin Maven Android à partir de la ligne de commande en utilisant la version courte du nom du plugin ‘android’, vous devez ajouter l’extrait de configuration suivant dans votre fichier settings.xml.


   
     com.jayway.maven.plugins.android.generation2

Utilisation du Maven Android Plugin dans un projet simple

Une fois que votre environnement est correctement configuré, vous pouvez configurer Maven pour construire vos applications Android. Pour cela, ajoutez ce pom.xml à la racine de votre application.


  
      4.0.0
      fr.xebia.android.demo.simple
      simple-android-project
      1.0-SNAPSHOT
      apk
      Simple Android Project
      
          
              android
              android
              2.1_r1
              provided
          
      
      
          src
          
              
                  com.jayway.maven.plugins.android.generation2
                  maven-android-plugin
                  2.2.3-SNAPSHOT
                  
                      
                          2.1
                      
                      true
                     true
                  
                  true
              
              
                  maven-compiler-plugin
                  
                      1.5
                      1.5

Ce pom.xml est tout à fait traditionnel excepté les points suivants :

Il dispose d’un nouveau type de packaging ‘APK’
Deux plugins sont configurés dans le build : Maven Android et Maven Compiler

Le type de packaging APK permet d’activer le cycle de vie spécifique à Android. Il fait le lien entre Maven et les outils du SDK Android, permet la gestion des ressources, la conversion du bytecode Java en code exécutable Dalvik …

La dépendance vers le JAR de la plateforme doit utiliser la version de la cible telle qu’elle a été publiée dans le dépôt Maven par l’Android SDK Deployer. Il récupère les versions à partir des valeurs Platform.Version et Pkg.Revision renseignées dans le fichier de propriétés source.properties qui se trouve dans le dossier de la plateforme du SDK Android.

La configuration du plugin Maven Compiler dans le build est également nécessaire, car Android utilise les fonctionnalités Java 5 (annotations, boucles simplifiées…).

Pour construire l’application et l’exécuter sur un émulateur déjà lancé, lancez la commande :

mvn clean install android:deploy

Ajoutez des tests à votre application Android

Le test du code d’une application Android peut-être effectué à la manière d’un test unitaire traditionnel junit dans le cadre du SDK Android, mais aussi par l’intermédiaire de tests d’intégration. Ces derniers sont appelés ‘instrumentation tests’.

Exécution des tests unitaires d’un projet Android via Maven

Le plugin Android Maven lance l’exécution des tests unitaires à la manière du plugin Surefire. Comme le chemin par défaut des classes de tests dans Eclipse et dans l’Android Development Toolkit ne respecte pas la convention Maven, vous devez configurer spécifiquement le dossier d’accès au code de vos tests unitaires.


  test
  ...

Gérez vos tests d’instrumentation Android avec Maven

Les tests d’instrumentation sont des tests d’intégration packagés dans une application qui est lancée dans un émulateur (ou un téléphone) et qui interagit avec une autre application pour tester son comportement. Pour exécuter les ces tests d’instrumentation, vous devez disposer de deux projets distincts : l’un pour l’application, l’autre pour les tests d’instrumentation. Ces modules sont liés par l’intermédiaire d’un pom parent.

La configuration du plugin Maven Android pour l’application contenant les tests d’instrumentation est la même que pour celle de l’application principale avec une seule différence : l’ajout d’une dépendance vers l’application principale. Il est important d’ajouter le type apk sur cette dépendance pour permettre au plugin Maven Android de trouver le package de l’application.


      fr.xebia.android.demo.simple
      simple-android-project
      1.0-SNAPSHOT
      apk

Rajoutez des Add-On à vos applications Android

Pour la majorité des applications, l’artefact du SDK (android.jar) suffit, il arrive pourtant que certaines applications nécessitent des Add Ons. L’un des Add-Ons les plus connus est celui de Google Maps. Cet Add-On a été déployé dans votre dépôt Maven par l’outil Maven Android SDK Deployer. Afin de pouvoir utiliser cette API, vous avez besoin d’ajouter une dépendance à votre application :


  com.google.android.maps
  maps
  7_r1
  provided

Découpez vos projets Android avec Maven

Le plugin Maven Android peut être utilisé sur un projet multi-module de manière transparente, voici comment je vais découper mes projets :

Le socle contient :

Une application contenant le code et les ressources Android communes à toutes mes applications Android

Chaque application contient :

Un projet pour le code Java réutilisé côté serveur. Cela permet de partager du code entre une application Android et une application Web.
Une application web de type WAR contenant la partie serveur de l’application. C’est cette partie qui fournit les services distants à l’application Android.
L’application Android proprement dite est un projet Maven de type APK qui possède une dépendance sur le modèle et une dépendance sur le socle. C’est son pom qui configure le plugin Maven Android. Notez le type particulier de la dépendance vers le socle : apksources, les sources et ressources incluses dans cette dépendance sont poussées dans l’application courante avant sa construction.


      fr.xebia.android.demo.socle
      socle-sample
      1.0-SNAPSHOT
      apksources


      fr.xebia.android.demo.simple
      simple-model
      1.0-SNAPSHOT

Un dernier projet contenant les tests d’intégration qui dépend de l’application précédente.


      fr.xebia.android.demo.simple
      simple-android-project
      1.0-SNAPSHOT
      apk

Notez cependant que ce plugin Maven Android est toujours en cours de développement, j’ai rencontré de nombreux bugs. Le dernier en date, et pas des moindres : la fonctionnalité ‘apksources’ ne fonctionnait plus. Utilisez ce genre de fonctionnalité que si vous n’avez pas peur de mettre les mains dans les sources du plugin en cas de problème. Tout cela sent encore la peinture fraîche, reste à savoir si elle va tenir.

La solution Maven ne vous a pas séduit ? Il est vrai qu’elle reste lourde et relativement compliquée, mais il existe bon nombre d’alternatives Ant, AndroidAnt, Eclipse Linked Source, ln -s …

Revue de Presse Xebia

Xebia France — Mon, 01 Mar 2010 18:25:17 +0000

La revue de presse de l’actualité Java/J2EE hebdomadaire proposée par Xebia.

Actualité éditeurs / SSII

Agilité

Utilisez-vous des métriques intelligentes sur vos projets ?

Le coin de la technique

Actualité éditeurs / SSII

Sonatype ouvre son dépôt maven pour java.net

L’idée est venue d’une quantité toujours grandissante de plaintes sur les dépôts Maven fournis par java.net. A l’heure de la fusion annoncée entre Kenai et java.net, Kenai n’a aucune solution pour gérer les dépôts et java.net fait mauvaise presse sur ce point. Il n’aura pas fallu longtemps à Sonatype pour saisir l’opportunité de mettre en avant sa solution Nexus. L’éditeur propose donc à tous les projets java.net de migrer vers leur instance Nexus OSS, allant même jusqu’à organiser le 5 mars une grande journée migration, avec la mise à disposition pour tous des services de conseil et d’ingénierie interne. Outre la performance et la stabilité du dépôt Maven maintenu par Sonatype, Nexus génère des fichiers d’index utilisés par nos IDE pour rechercher les dépendances de nos POM.

La fusion JRockIt / Hotspot pas pour demain

Nous en parlions il y a quelques semaines, Oracle envisage de ne proposer à l’avenir qu’une seule JVM, qui tirerait le meilleur des deux que la firme s’est offert (JRockit via BEA, et Hotpsot via Sun). Dans un récent webcast (via InfoQ), Mark Reinhold s’est exprimé sur le sujet. Cette fusion n’est pas pour tout de suite : trop de clients utilisent les fonctionnalités spécifiques à l’une ou l’autre des JVMs en production, et il serait risqué de les forcer à migrer vers une version fusionnée bancale. Ce dernier se dit jaloux de certaines fonctionnalités de JRockIt et donc particulièrement excité d’avoir l’occasion de l’étudier en profondeur. Cependant, ce qui transparait dans son discours (et peut être via nos diverses expérience), c’est que la JVM de Sun est en avance sur celle de BEA. La prochaine version fusionnée devrait donc tendre plus vers Hotspot que vers JRockit. En résumé rapide, cette future VM Oracle devrait avoir les fonctionnalités runtime de Hotspot, et le garbage collector et la robustesse de JRockit. Finalement, à part l’ébauche d’une timeline, nous ne sommes pas beaucoup plus avancés.
Coté nouveautés du JDK 7, Mark Reinhold se dit aussi particulièrement excité par l’intégration du projet Coin (au contraire de la grande majorité des consultants Xebia, qui trouvent que la plupart de ces évolutions syntaxiques confinent au gadget).
Il reparle aussi des closures, principalement sous l’angle des raisons de la polémique, mais personne ne semble réellement savoir comment elles seront implémentées dans le JDK 7 (voir ci-dessous pour l’avancement du projet Lambda).
Dernière annonce, pour ceux qui comme lui sont impatients de voir une JVM enfin modulaire (aka Jigsaw, prévu dans le JDK 7, voir ci-dessous), ils devraient en avoir un aperçu mi-mars, avec la release 88 de l’OpenJDK.

Certains noteront avec un certain amusement (ou une certaine nostalgie) quelques ratés : « We, at Sun… »

Agilité

Utilisez-vous des métriques intelligentes sur vos projets ?

Mike Griffiths, agiliste expérimenté et bloggeur actif, nous présente sa réflexion sur l’utilisation des métriques dans un projet.
Au préalable, Mike nous prévient que :

Toutes les observations ne sont pas utiles et d’une grande aide pour analyser et comprendre un phénomène. Elles peuvent même amener à de mauvaises conclusions.
Certaines mesures très utiles ne sont pas facilement observables.

Une autre caractéristique à ne pas négliger est l’effet Hawthorne : L’observateur influence la mesure. On retrouve d’ailleurs ce phénomène en physique quantique. Mike nous explique alors que le fait d’observer et donc d’influencer la mesure, à un effet positif.

Pour lui, une métrique « intelligente » doit avoir les caractéristiques suivantes :

Simple et auto-générée.
Influence de manière significative ce que l’on cherche à observer.
Permet de prendre des décisions et décrire des tendances pour le futur.

Mike nous conseille de donner plus d’attention aux métriques permettant d’observer des tendances futures et d’anticiper.

On peut ainsi opposer aux vieilles métriques : nombres de lignes codées, points de fonctions réalisés ou nombres d’heures travaillées ; des métriques plus « intelligentes » : confiance des sponsors, satisfaction client, nombre de fonctionnalités réalisées, ou encore temps passé à la correction de bugs.

Dans la dernière partie de l’article sont présentés un certain nombre de métriques plus ou moins connues des agilistes, comme : le taskboard de Scrum ou Kanban. L’utilisation de métriques intelligentes est indispensable pour mener à bien un projet. Elles permettent d’observer des tendances, d’identifier et d’anticiper des problèmes; et ainsi, de prendre les bonnes décisions.

Le coin de la technique

Jigsaw, les modules du pauvre ?

Adam Bien est l’un des Java champions les plus visibles et les plus lus d’internet. Il a publié cette semaine un petit article au titre accrocheur : « Jigsaw / JDK 1.7 sera une solution qui permettra de répondre à 80% des besoins de modularité ». Vous avez probablement suivi les différents épisodes et rebondissements de la modularité dans le JDK 7. C’est peut-être l’occasion de faire le point sur ce que propose Jigsaw.

Le projet Jigsaw proposera une implémentation permettant la mise en place d’un système de modules bas niveau pour vos projets. Il sera également utilisé en interne pour découper le JDK Oracle/Sun lui-même.

Jigsaw vous permettra de choisir tout ou partie du JDK tout en restant 100% rétro-compatible, d’améliorer les temps de démarrage de la JVM et son utilisation mémoire.
Jigsaw pourra être utilisé directement sur vos projets si vous disposez d’une JVM reposant sur ce système. Jigsaw sera chargé avant rt.jar et sera donc disponible à quiconque désirant l’utiliser. Ce projet étant open source, il sera également possible de réutiliser celui-ci dans d’autres contextes.
Jigsaw vous permettra de rendre vos applications modulaires progressivement. Nul besoin de migrer vos applications dans leur ensemble pour tirer parti des bénéfices de la modularité. Un même package peut être éclaté dans plusieurs modules.
Contrairement à OSGi, Jigsaw ne vous permet pas le rechargement de modules à chaud. Vos modules sont chargés statiquement au démarrage de vos applications.
Tous vos modules sont chargés dans un même classloader, cela permet de simplifier grandement son utilisation. Du même coup, il vous sera probablement possible de ‘tricher’ en chargeant, au runtime, des classes d’un module sans que vous en ayez réellement le droit.

Si vous confondiez modularité du JDK avec OSGi, cette liste vous a certainement ouvert les yeux : Jigsaw vous propose une solution beaucoup moins fournie qu’OSGi.

Dans les faits, ce projet a été créé, avant tout, pour casser notre bon vieux JDK monolithique. Bon nombre de polémiques ont été faites sur ce choix. Pourquoi se contenter d’aborder 80% des problématiques de la modularisation avec une nouvelle solution alors qu’OSGi en aborderait 90% ? La simplicité et la souplesse d’utilisation ont été préférées à une solution décrite comme lourde (nécessitant beaucoup de glue), vieillissante (datant de 1998) et difficile à maîtriser. Ce choix a été sans conteste difficile à effectuer, il s’est ailleurs attiré les foudres des défenseurs d’OSGi, mais reste complètement défendable.

Comment les closures seront implémentées dans OpenJDK 7 ?

Fin 2009, le projet Lambda, dont le but est d’apporter les closures à la prochaine version de Java, apparaissait au sein d’OpenJDK. Le lancement du projet faisait suite aux rebondissements dans l’actualité du JDK 7 lors de la conférence Devoxx un mois auparavant. Une documentation montrant la syntaxe des closures avait accompagné la création du projet, plus tard, un draft d’une spécification plus formelle est apparue, mais quid de l’implémentation ?
Rémi Forax, contributeur au projet Lambda, a mis à disposition la présentation qu’il a faite au FOSDEM’10, dans laquelle il résume les discussions ayant eu lieu sur la mailing list du projet concernant les possibilités d’implémentation :

Convertir les closures en classes anonymes. Cette solution présente l’inconvénient de produire beaucoup de classes et pose problème pour certaines constructions liées au closures.
Convertir les closures en invocations dynamiques telles que le permettra la JSR-292 (Supporting Dynamically Typed Languages on the Java Platform). Cette solution ne produit pas de classes supplémentaires et bénéficie de bonnes performances puisque l’invocation dynamique présentera un temps d’exécution similaire aux invocations de méthode classiques.

Le reste de ses slides présente certaines des problématiques d’implémentations des closures liées à l’accès aux variables locales et aux champs de la classe hôte.

L’actualité des bases de données NoSQL toujours aussi riche

Depuis plusieurs mois maintenant le mouvement NoSQL s’est installé dans l’actualité. A Paris, le NoSQL User Group a attiré l’attention en réunissant une cinquantaine de personnes à chacune de ses 2 sessions jusqu’à présent.

D’un point de vue plus général, l’actualité des bases de données NoSQL est marquée par l’intérêt croissant qu’elles suscitent, et par leur évolution rapide grâce à l’effort soutenu de leurs développeurs. Ainsi on a pu noter récemment :

Neo4j, une base de données orienté graphe, est maintenant disponible en version 1.0 finale. L’intérêt de la représentation en graphe est la possibilité de modéliser les données relatives aux réseaux sociaux, mais également tout type d’objets qui seraient liés entre eux de manière arbitraire. De plus, il est possible d’appliquer à ces données divers algorithmes de graphe classiques tels que la détermination du plus court chemin entre deux objets ou de l’objet central/majeur dans un nuage d’élément.
Cassandra vient pour sa part d’être publié en version 0.5.1, et connait un succès tout particulier puisque Twitter vient d’annoncer qu’il l’utiliserait désormais comme solution de persistance en remplacement de MySQL. Par ailleurs le projet Lucandra a été créé récemment pour permettre d’utiliser Cassandra comme solution de persistance pour les indexes Lucene. Donné à la Fondation Apache par Facebook, Cassandra est pour rappel un hybride entre BigTable de Google et Dynamo d’Amazon.
HBase profite d’une communauté très active et d’un intérêt important, renforcé par sa position de sous-projet du très populaire Hadoop. Sematext vient de publier un digest de l’actualité récente de ce projet. Celle-ci est principalement marquée par le développement d’une réplication multi datacenter, par l’arrivée d’un plugin DataNucleus pour HBase et par la disponibilité prochaine d’une solution de benchmark pour les cloud storages développée par Yahoo!.

Enfin, deux conférences entièrement dédiées au NoSQL sont à venir : NoSQL Live le 11 mars à Boston et, plus proche de nous, NoSQL Europe du 20 au 22 avril à Londres.

Astuce de la semaine, récupérez la liste complète des options de votre JVM

Cette astuce est complètement inutile, et donc également complètement indispensable. Cet article nous propose une petite commande permettant de récupérer la liste complète des options de votre JVM Hotspot à partir de sa library native Linux, la voici :

prompt$  strings $JAVA_HOME/jre/lib/amd64/server/libjvm.so | grep -B646 assert_null$ | grep -v '{' | grep -v '&' | grep -v '/' | grep -v '%' | grep -v assert_null

Revue de Presse Xebia

Xebia France — Mon, 08 Feb 2010 17:06:14 +0000

La revue de presse de l’actualité Java/J2EE hebdomadaire proposée par Xebia.

Actualité éditeurs / SSII

Kenaï, fermera, fermera pas ?

Le coin de la technique

Actualité éditeurs / SSII

Kenaï, fermera, fermera pas ?

Comme il fallait le prévoir au vu de l’engouement d’Oracle pour les projets communautaires, la ferme de projets Kenaï vit ses derniers jours en tant que service public. La plateforme lancée en 2008 et construite autour de JRuby, Glassfish et MySQL fournissait un environnement de suivi de projet complet avec la gestion de version, des wikis, des mailing lists et que sais-je encore. Avec NetBeans 6.7, il est même possible de maintenir entièrement son projet depuis son IDE. Le site héberge encore aujourd’hui quelques 40 000 projets communautaires parmi lesquels on retiendra JRuby et Hudson. Oracle a d’abord annoncé la fermeture du site sous 60 jours afin de permettre aux projets de migrer vers d’autres solutions. L’idée de départ devait être de ré-utiliser la plateforme en interne mais plus du tout ouverte au public.
Faut il y voir les effets de la réaction d’une communauté importante ou un gros problème de communication : Oracle change son fusil d’épaule à travers la voix de Ted Farrell qui a clarifié l’avenir de la plateforme en annonçant que ce serait finalement une migration vers java.net. Dans son annonce, Farrell laisse entendre que tous les efforts seront poussés sur java.net et que la communauté Kenaï pourrait continuer à travailler sans perte sur la nouvelle version de cette ancienne plateforme de développement hosté.
Comme le dit la chanson, trois pas en avant, trois pas en arrière, …

Le coin de la technique

Groovy++: bientôt dans votre JVM ?

Nous avons éhontément passé sous silence nombre de news du monde Groovy récemment:

Groovy 1.7
Grails 1.2
La sortie du plugin Groovy Eclipse en version 2.0
La sortie de nouvelles versions de Griffon, le framework pour clients lourds qui reprend les idées de Grails

Alors pour nous rattraper, nous ne passerons pas à coté de la nouvelle suivante : le développement de Groovy++ ! Alex Tkachman, l’initiateur du projet nous explique dans une interview de quoi il retourne et Roshan Dawrani nous explique ce qu’il retient du projet. En fait, malgré tous ses avantages, Groovy est encore assez lent. En tout cas beaucoup plus que Java, à cause de son coté dynamique. L’idée de Groovy++ est de continuer à utiliser Groovy normalement, mais en pluggant un compilateur spécial pour certaines parties du code annotées avec @Typed. Le code ainsi annoté devra respecter de légères contraintes (contraintes par rapport au laxisme de Groovy, mais légères par rapport au typage fort de Java). Le compilateur pourra donc effectuer des optimisations, notamment grâce à l’inférence de type, et nettement améliorer les performances. Les premiers résultats semblent encourageant en tout cas : 197 fois plus rapide d’après ce micro-bench et 33% plus rapide d’après cet article lu sur le Touilleur Express.

Alors ce Groovy++, une révolution ? Difficile à dire ! En effet, d’un coté Groovy est de plus en plus utilisé (notamment à travers Grails) et un coup de boost ne peut pas lui faire de mal. Mais d’un autre coté, l’interaction de Groovy et Java étant très avancée, on peut se contenter d’écrire en Java les parties du programme nécessitant des performances optimales. On peut aussi voir en Groovy++ l’ajout d’une énième librairie dans le développement, avec ses contraintes, ses bugs… D’autant que, pour des problèmes de licence sur certaines parties de code, le compilateur n’est pas encore OpenSource (ce qui est prévu pour la suite). Donc, si vous sous sentez l’âme d’un aventurier ou que vous avez désespérément besoin de gains de performances tout en gardant la « Groovy attitude », n’hésitez pas à nous faire vos retours sur l’utilisation de Grovvy++ !

InfoQ sort un ebook gratuit sur Grails

InfoQ vient de sortir, dans sa série « Minibooks » la seconde version de son « Getting started with Grails ». La première version, datant d’il y a déjà 3 ans, était basée sur Grails 0.3.1 alors que celle-ci s’appuie sur le tout récent 1.2. Le principe reste identique : les auteurs s’appuient sur une application de gestion de course de chevaux pour nous faire découvrir au fur et à mesure nombre des possibilités offertes par le framework. A la vue du sommaire, largement remanié, on peut penser que les changements ont été profonds. Sans avoir encore lu cette seconde édition, nous pouvons d’ores et déjà la recommander chaudement à toute personne qui s’intéresse à Grails et voudrait rapidement avoir un éventail clair des possibilités qu’il offre (si elle est dans la même veine que la précédente). D’autant qu’au format électronique, le livre est gratuit (juste besoin de s’inscrire à InfoQ)!

Maven vers une injection de dépendances via Guice

Sonatype (via InfoQ) a annoncé la migration progressive de Maven vers une injection de dépendances gérée par Google Guice. Ce qui signifie l’abandon à moyen terme de Plexus, le framework quelque peu obsolète (et abscons, faute de documentation) utilisé depuis les débuts du framework de build. Dans un premier temps, la migration sera gérée via un bridge créé sous Guice.
De plus, l’introduction de Guice devrait se faire via les annotations de la JSR 330, ce qui rendra Maven moins adhérent à Guice dans le cas d’une nouvelle migration vers un autre framework d’IoC.
Cette nouvelle devrait réjouir les développeurs de plugins, qui n’auront plus à maitriser les arcanes de Plexus. Autre conséquence, plus directe, les développeurs Maven n’auront plus à jouer les comitters Plexus pour débugger et ou faire avancer cet outil (qui devrait rapidement se diriger vers une fin de vie en l’absence de ce soutien de poids).
On peut noter que Jason van Zyl, le créateur de Maven, et Bob Lee, l’un des principaux artisans de Guice, avaient œuvré ensemble à imposer la JSR 330 face à la JSR 299 (la fameuse bataille @Inject contre WebBeans).

Comment séparer ses tests d’intégration ?

Nathaniel Richand — Wed, 13 Jan 2010 11:28:40 +0000

Une question récurrente pour les équipes qui commencent à industrialiser leur build avec du Maven et qui utilisent de manière intensive JUnit. Au bout d’un moment, les tests d’intégrations ralentissent de manière conséquente le build et parfois découragent les développeurs à cause de leurs pré-requis plus importants que les tests unitaires.
Comment les séparer des tests unitaires et comment éviter qu’ils soient lancés à chaque build Maven?

Test unitaire ou test d’intégration

La démarcation entre les tests unitaires et les tests d’intégrations est souvent floue et longuement débattue sur un projet.

Ce qui caractérise avant tout les tests unitaires, c’est leur périmètre réduit et surtout leur rapidité d’exécution (cf. les 10 commandements des tests unitaires). De même, les tests unitaires ne doivent pas avoir de pré-requis complexes et ne pas dépendre d’un système extérieur pouvant être indisponible (une base de donnée, un service fourni par une autre application, un broker JMS, etc.).

Il est très important de soigner ses tests unitaires pour que ceux-ci restent une véritable aide au développement. Si l’un d’eux échoue pour une raison extérieure au test et au code testé, ou bien s’ils deviennent de plus en plus lents, vous allez voir fleurir des » @Ignore » et les développeurs vont prendre l’habitude de builder en rajoutant l’option « -Dmaven.test.skip ». Enfin avec le temps, les tests vont devenir une contrainte plus qu’une aide et vont progressivement disparaître.

Cependant, nous ne voulons pas pour autant faire une croix sur les tests d’intégration. Ceux-ci sont très utiles pour vérifier le lien entre les différentes parties, ou faire des tests plus élaborés. De même, ils restent indispensables sur certaines couches, notamment les couches DAO ou WebServices où l’utilité de tests unitaires reste à voir. En effet quel est l’intérêt de tester le bon fonctionnement d’un mock ?

La question à laquelle nous allons tacher de répondre est donc : comment séparer de manière propre ces différents types de tests ?

Comment faire avec Maven

Séparer les tests d’intégration dans un module à part

Il existe plusieurs façons de procéder avec Maven, la plus simple étant de placer les tests d’intégration dans un module séparé du reste du projet. Bien que facile à mettre en place, cela a pour effet de décorreler les sources des tests et de multiplier les modules.

Dans le même ordre d’idées, on peut envisager de créer un seul module qui contiendrait tous les tests d’intégration. Cependant, cette approche n’est envisageable que si le projet contient un nombre très réduit de modules. Le code de test doit être traité avec autant d’égard que le reste du code. Tout comme on essaye de bien segmenter le code en parties logiques, on essaiera également de ne pas transformer ses tests en grand plat de spaghettis.

Utilisation des profiles maven

L’approche recommandée est la séparation via un profil dédié et la différenciation des tests d’intégration par pattern. Le but est de définir une convention pour cataloguer ses tests d’intégration :

soit sur le nom de la classe (ex : *ITest.java)
soit sur le nom du package (ex : **/integration/**)

Exemple de séparation sur le nom de package :

Tout d’abord on enlève toutes les classes contenues dans un package » integration » des tests.


	
        	
			org.apache.maven.plugins
			maven-surefire-plugin
			2.4.2
			
				true
			
			
				
					surefire-test
					test
					
						test
					
					
						false
						
							**/integration/**

Puis, on redéfinit la phase » integration-test » en lui intégrant les classes contenues dans les package » integration « .


	integration-testing
	
		
			
				org.apache.maven.plugins
				maven-surefire-plugin
				2.4.2
				
					true
				
				
					
						surefire-itest
						integration-test
						
							test
						
						
							false
							
								**/integration/**

Cette approche a l’avantage de garder dans un même module les tests d’intégration et le code, tout en les regroupant sous un même package. Cependant, le seul point faible de cette approche réside dans le fait que le test d’intégration ne se retrouve plus dans le même package que la classe testée. Ainsi, on ne pourra plus accéder aux variables et méthodes protected.

Futur?

L’approche idéale dans Maven serait de séparer les tests d’intégrations de la même manière que les tests sont séparés du code. On pourrait ainsi avoir :

+- main
  +-- java
  +-- resources
+- test
  +-- java
  +-- resources
+- it
  +-- java
  +-- resources

Cette possibilité est très attendue par les développeurs mais impossible avec Maven2.
Maven3 le permettra-t-il ? Pour l’instant aucune information n’a filtré à ce sujet…

Comment faire avec le runner JUnit de Spring

Spring propose une surcouche à JUnit en l’enrichissant de nouvelles fonctionnalités. Celle qui nous intéressera particulièrement est l’utilisation du runner JUnit : SpringJUnit4ClassRunner en plus de l’annotation @IfProfileValue . Celle-ci permet de catégoriser les tests. Ceux étant annotés ainsi ne seront exécutés que si une variable d’environnement équivalente au contenu de l’annotation est présente dans le classpath.

import org.junit.Test;
import org.junit.runner.RunWith;
import org.springframework.test.annotation.IfProfileValue;
import org.springframework.test.context.ContextConfiguration;
import org.springframework.test.context.junit4.SpringJUnit4ClassRunner;
@RunWith(SpringJUnit4ClassRunner.class)
@ContextConfiguration(locations={"/test-configuration.xml"})
public class IntegrationTest {
	@IfProfileValue(name="test-group", value="integration")
	@Test
	public void test(){
		...
	}
}

De base, nos tests annotés ne sont pas exécutés. Pour qu’ils soient exécutés, il suffit de les lancer en rajoutant comme argument : -Dtest-group=integration.

Si vous utilisez Eclipse et que vous souhaitez activer vos tests d’intégrations par défaut, rien de plus simple :

En conclusion, cette solution offre l’avantage d’être assez souple et de pouvoir regrouper dans une même classe différents types de tests.

Comment faire avec TestNG

TestNG est un framework de tests offrant de nombreuses fonctionnalités supplémentaires par rapport à JUnit. Avec TestNG il est possible de spécifier le ou les groupes de tests concernés directement dans l’annotation @Test.

@Test(groups = "integrationTest")
public class Test {
  public foo() {}
  public bar() {}
}

Pour exclure des groupes de tests en utilisant TestNG, il suffit de lui rajouter l’option -excludegroups= »xxx,yyy ».
Si vous utilisez Maven il faut configurer Surefire de la sorte :


    org.apache.maven.plugins
    maven-surefire-plugin
    2.4.2
    
      integrationTest

Cette solution est surement la plus complète et la plus souple avec les notions de groupe de groupes, groupes partiels, etc. (cf. documentation)

Et pour JUnit?

Attendue depuis longtemps par la communauté, JUnit propose dans sa version 4.8 une fonctionnalité expérimentale, les @Category (Voir la présentation de David Saff) :

public interface SlowTests {}
public class A {
   @Category(SlowTests.class)
   @Test
   public void testA(){
   }
}
@RunWith(Categories.class)
@IncludeCategory(SlowTests.class)
@SuiteClasses( { A.class})
public class SlowTestSuite {
}

Cette solution n’est cependant pas encore très mature. En effet, il est nécessaire de créer une interface pour chaque type de test et il faut impérativement définir manuellement la suite de tests en y ajoutant une à une les classes de tests à inclure (même s’il existe quelques astuces). De plus, le lien avec le plugin Surefire de Maven n’existe pas encore.
Cette solution est donc une alternative à surveiller mais pas encore à utiliser.

Conclusion

Comme nous venons de le voir, il existe de nombreux moyens pour séparer nos différents types de tests. Attention cependant à ne pas utiliser cette technique pour masquer les test gênants. Si vous avez des soucis avec certains tests, mieux vaut s’attaquer à la source même du problème plutôt qu’à ses conséquences. De plus, cette séparation doit être une aide aux développeurs uniquement, il est primordial de demander au serveur d’intégration continue de lancer l’intégralité des tests. Ou bien de le paramétrer avec deux builds : un à la volée très rapide et un exécuté une fois par jour qui lancera l’intégralité des tests.

Maven Definitive Guide FR, relecture finale

Erwan Alliaume — Fri, 04 Dec 2009 06:04:08 +0000

Les 19 chapitres de la traduction officielle du Maven Definitive Guide terminés, il est grand temps de nous lancer dans la dernière ligne droite avant la fin du projet : la relecture publique complète de la traduction. En tant que participant à ce projet, c’est avec un certain enjouement (ndlr : ouf, c’est fini !) que je relaie donc cet appel pour relire les 430 pages de ce guide. Je profite de cette occasion pour remercier les relecteurs de la première partie, et espère vous voir au moins aussi nombreux cette fois-ci. Notez que nous avons besoin de tout type de contributeur : vous lancer dans la relecture ne signifie pas forcément vous engager sur la relecture complète du livre.

Pour ceux que ça intéresserait, veuillez noter les points suivants :

Les chapitres 1 à 8 (toute la première partie) ont déjà été relus fin septembre, privilégiez les suivants.
Il est préférable de nous contacter avant de vous lancer dans la relecture, nous pourrons ainsi répartir uniformément les relectures et éviter les corrections parallèles.
Privilégiez les versions HTML ou PDF pour la relecture.

Pour bien démarrer :

Build journalier de la traduction ;
Sources de la traduction sur notre projet GitHub ;
Créez un compte sur github pour pouvoir nous soumettre vos retours via l’Issue Tracker et télécharger la version XML du docbook ;

N’hésitez pas à en parler autour de vous, que ce soit à l’oral, par mail, ou sur vos blogs
Bonnes relectures.

Maven Definitive Guide FR – chiffrez vos mots de passe

Erwan Alliaume — Fri, 27 Nov 2009 15:52:25 +0000

Pour en avoir parlé fin septembre, vous savez peut-être que je participe à la traduction française du Maven Definitive Guide. Comme vous pouvez le constater, la traduction est maintenant bien avancée, nous lancerons d’ailleurs probablement très bientôt les demandes de relecture de la seconde et dernière partie (vous en serez informé sur ce blog).

Je profite de cette occasion pour vous en présenter un extrait en prenant l’exemple d’une fonctionnalité que je ne connaissais pas avant de m’y atteler : comment chiffrer vos mots de passe dans vos Settings Maven.

Si vous utilisez Maven pour déployer vos artefacts sur des dépôts distants ou tout autre service distant nécessitant l’utilisation de mots de passe, la meilleure solution est de stocker ces mots de passe dans vos Settings Maven. Sans un mécanisme pour chiffrer ces mots de passe, le fichier ~/.m2/settings.xml devient rapidement une faille de sécurité, car il contient les mots de passe d’accès à vos différents serveurs en clair. Pour éviter ce problème, Maven 2.1 a introduit une fonctionnalité qui permet de chiffrer vos mots de passe. Pour ce faire, vous devez commencer par créer un mot de passe maître et stocker celui-ci dans un fichier de security-settings.xml à l’emplacement ~/.m2/settings-security.xml. Vous pouvez ensuite utiliser ce dernier pour chiffrer vos autres mots de passe, ceux que vous deviez stocker en clair dans vos Settings Maven (~/.m2/settings.xml).

Pour illustrer cette fonctionnalité, regardons le processus utilisé par Maven pour récupérer le mot de passe non chiffré d’un serveur à partir des paramètres d’un utilisateur. Le schéma ci-dessous présente ce processus. Un utilisateur peut faire référence à un serveur en utilisant un identifiant dans le POM d’un projet, Maven recherche alors le serveur correspondant dans ses settings. Une fois trouvé, Maven utilisera le mot de passe associé à celui-ci. Le mot de passe est stocké en clair dans ~/.m2/settings.xml, il est donc facilement accessible à toute personne qui dispose des droits de lecture sur ce fichier.

Maintenant, regardons comment Maven utilise des mots de passe chiffrés. Le diagramme ci-dessous présente ce processus.

Pour configurer la fonctionnalité de chiffrage des mots de passe, créez le mot de passe maître en exécutant l’une des commandes suivantes :

shell> mvn -emp 
{rsB56BJcqoEHZqEZ0R1VR4TIspmODx1Ln8/PVvsgaGw=}

shell> mvn --encrypt-master-password 
{rsB56BJcqoEHZqEZ0R1VR4TIspmODx1Ln8/PVvsgaGw=}

Maven affiche alors une copie de la version chiffrée du mot de passe sur la sortie stantard. Copiez celui-ci et collez-le dans le fichier ~/.m2/settings-security.xml comme le montre l’exemple suivant.


  {rsB56BJcqoEHZqEZ0R1VR4TIspmODx1Ln8/PVvsgaGw=}

Après avoir créé le mot de passe principal, vous pouvez commencer à chiffrer vos mots de passe pour les utiliser dans vos settings. Pour chiffrer un mot de passe à l’aide du mot de passe maître, utilisez l’une des commande suivante mvn -ep ou mvn --encrypt-password. Imaginons que vous disposez d’un gestionnaire de dépôt et que vous avez besoin d’un utilisateur « deployment » et d’un mot de passe « qualityFIRST » pour vous y connecter. Pour chiffrer ce mot de passe, utilisez la ligne de commande suivante :

shell> mvn -ep qualityFIRST
{uMrbEOEf/VQHnc0W2X49Qab75j9LSTwiM3mg2LCrOzI=}

Copiez ensuite le mot de passe chiffré affiché sur la sortie standard et collez-le dans vos settings Maven.


  
    
      nexus
      deployment
      {uMrbEOEf/VQHnc0W2X49Qab75j9LSTwiM3mg2LCrOzI=}
    
  
  ...

Lorsque vous exécutez un build Maven qui a besoin d’interagir avec le gestionnaire de repository, Maven récupérera le mot de passe principal à partir du fichier ~/.m2/settings-security.xml et utilisera celui-ci pour déchiffrer le mot de passe stocké dans votre fichier ~/.m2/settings.xml. Maven utilisera ce mot de passe déchiffré pour se connecter au serveur.

Quels sont les bénéfices d’un tel mécanisme ? Il vous permet d’éviter de stocker en clair vos mots de passe dans le fichier ~/.m2/settings.xml. Notez que cette fonctionnalité ne prévoit pas le chiffrage du mot de passe lors de l’envoi de celui-ci sur le serveur distant. Il est toujours possible, pour une personne mal intentionnée, de récupérer vos mots de passe en analysant les flux réseau.

Pour encore plus de sécurité, vous pouvez demander à vos développeurs de stocker le mot de passe maître chiffré sur un périphérique de stockage amovible comme un disque dur USB. En utilisant cette méthode, un développeur doit brancher son disque amovible sur sa station de travail lorsqu’il veut effectuer un déploiement ou une quelconque interaction avec un serveur distant. Pour cela, votre fichier ~/.m2/settings-security.xml doit contenir une référence vers l’emplacement réel de votre fichier settings-security.xml. Cette configuration passe par l’utilisation de la balise relocation.


  /Volumes/usb-key/settings-security.xml

Ainsi, le développeur peut stocker son fichier settings-security.xml sur son emplacement personnalisé /Volumes/usb-key/settings-security.xml et s’arranger pour que ce fichier ne soit disponible que s’il est assis devant sa station de travail.

Devoxx – Jour 4 – Maven Reloaded

Michaël Figuière — Fri, 27 Nov 2009 12:47:03 +0000

Jason van Zyl, le leader emblématique du projet Maven, était présent à Devoxx pour présenter les nouveautés à venir dans l’environnement Maven : Maven 3.0 et 3.1, finalisation de M2Eclipse, améliorations à venir sur Nexus ; le contenu était dense.

Il commence sa présentation en s’excusant pour la version 1.0 de Maven qui relevait de l’expérimentation et n’était pas destinée à une telle diffusion. La version 2.0 présentait quant à elle de nombreux défauts, il le reconnaît également. Il promet alors un outil mature et abouti avec Maven 3.0.

Le projet a stagné pendant plusieurs années ne laissant la place à aucune amélioration majeure. La complexité du code source de Maven, basé sur Plexus, un conteneur d’injection de dépendances qui lui est propre, en est pour partie la raison. Jason van Zyl explique ainsi que peu de développeurs contribuent au core du projet, en comparaison de la large communauté travaillant sur des plugins.

Cette stagnation liée aux défauts de Maven 2.0 a conduit à la création de nombreux projets alternatifs qui gagnent en popularité : Ivy, Gradle, Buildr, … A ce sujet, le leader du projet Maven voit cette concurrence comme bénéfique mais insiste sur le besoin de conserver une compatibilité entre les artefacts produits par l’ensemble de ces outils.

Que fait Sonatype ?

Sonatype a été créé il y a plusieurs années par Jason van Zyl. Au-delà de Maven, l’entreprise contribue à de nombreux projets :

M2Eclipse : le principal plugin Maven pour Eclipse, son concurrent direct Eclipse IAM étant encore au stade embryonnaire
Nexus : un repository Maven
Hudson : un serveur d’intégration continue très populaire
Tycho : un plugin Maven pour le développement Eclipse et OSGi
Flexmojos : un ensemble de plugins Maven pour le développement Flex
Pax : un plugin Maven pour OSGi
Maven-bundle-plugin : un plugin Maven facilitant la création de bundle OSGi

Maven 3.0 : polyglotte et plus performant

Comme expliqué en introduction, cette nouvelle version constituera une évolution importante pour Maven. Jason van Zyl annonce une finalisation autour de fin janvier 2010.

Compatibilité ascendante

Du fait de la très vaste utilisation de Maven, la compatibilité ascendante est incontournable.

Ainsi, Jason van Zyl explique que de nombreux tests d’intégration ont été réalisés afin d’assurer que l’ensemble des projets Maven 2.0 seront entièrement compatibles avec Maven 3.0. La majorité des plugins seront compatibles sans réécriture. Toutefois, certaines modifications d’API introduites dans Maven 3.0 ne pourront être compensées par les mécanismes de compatibilité mis en place.

Dans la pratique, on peut donc s’attendre à une phase de démarrage pendant laquelle chacune des équipes qui maintiennent des plugins devront assurrer leur compatibilité avec Maven 3.0.

Améliorations

Exécution multi-threadée

Peu avant Devoxx, Jason van Zyl annonçait sur le blog de Sonatype que les simplifications d’architecture apportées par Maven 3.0 avaient permis de mettre en œuvre une amélioration espérée depuis longtemps : l’exécution du build sur plusieurs threads.

Dans un contexte où la construction d’un projet d’entreprise avec Maven peut très souvent prendre plusieurs minutes, cette amélioration pourra justifier à elle seule la migration vers Maven 3.0.

Composition de POM avec les mixins

Les mixins seront introduit dans Maven 3.0. Ils permettront de créer des POM par composition, chaque fragment importé peut ainsi être déployé en tant qu’artefact. L’héritage multiple que les mixins constituent sera linéarisée en interne afin de retrouver une chaine d’héritage simple.

Simplification de l’intégration

Une meilleure intégration à M2Eclipse permettra des builds incrémentaux évitant ainsi de ré-exécuter l’ensemble du cycle de vie à chaque fois. Maven 3.0 offrira également des points d’extension pour le cycle de vie. Il sera ainsi possible de définir des actions à exécuter avant et après l’ensemble du cycle de vie. Enfin, Maven sera plus facilement intégré dans les IDEs ou dans les serveurs d’intégration continue, en permettant un meilleur contrôle de son comportement par son hôte.

Polyglot Maven

Il sera possible d’écrire les POMs dans un autre langage que XML. La structure de données restera identique, mais il sera possible d’utiliser la syntaxe de Groovy, Ruby, Scala, Python ou YAML. Il sera possible de transformer les POMs d’une représentation à l’autre ce qui permettra d’assurer la compatibilité au niveau du repository en y déployant toujours un POM en XML. Dès lors, le choix de la représentation dépendra des préférences des développeurs.

L’exemple ci-dessous montre un POM simple représenté en Groovy :

project {
    modelVersion '4.0.0'
    parent {
        artifactId 'xebia-parent'
        groupId 'fr.xebia'
        version '1.0.0-SNAPSHOT'
    }
    artifactId 'xebia-polyglotmaven-test'
    version '1.0.0-SNAPSHOT'
    name 'Polyglot Maven Test'
    url 'http://blog.xebia.fr'
    build {
        testResources {
            testResource {
                filtering 'true'
                directory 'src/test/resources'
            }
        }
    }
    dependencies {
        dependency {
            groupId 'junit'
            artifactId 'junit'
            version '4.7'
            scope 'test'
        }
    }
}

Polyglot Maven ne sera pas en standard dans Maven 3.0, il s’agira d’une extension.

Maven Shell

Le Maven Shell est une extension pour le moins inattendue mais qui s’est montrée convaincante. Il s’agit d’un environnement d’exécution pour Maven qui, dans sa version interactive, permet à l’utilisateur de saisir ses commandes Maven comme dans le shell natif de son système d’exploitation. Tout l’intérêt est alors le gain de performance qu’il est possible de réaliser grâce à la conservation en cache des données du reactor Maven entre chaque exécution.

Démonstration de Jason van Zyl: une première exécution du build en 14 secondes, il relance alors la même commande une seconde fois en seulement 7 secondes.

Maven Shell offre également un environnement interactif avec des nombreuses commandes supplémentaires, simplifiant les tâches Maven courantes. Il pourra être intégré à Hudson et à Nexus pour faire bénéficier à ces serveurs de fonctionnalités Maven plus puissantes.

Maven 3.1 : l’arrivée de Guice

Plexus, le conteneur d’injection de dépendance historique de Maven, sera remplacé par Guice dans Maven 3.1. Cette simple décision aura pour conséquence de simplifier la lisibilité du code source, le développement des plugins, et donc d’élargir la communauté de développeurs travaillant sur le projet. Jason van Zyl explique vouloir se baser au maximum sur la JSR 330 (Dependency Injection for Java).

Peaberry, l’extension OSGi de Guice, sera également utilisée, ce qui apportera à Maven une modularité standardisée pour ses plugins.

Là où l’ensemble des nouveautés introduites par Maven 3.0 permettent la compatibilité ascendante, Maven 3.1 sera plus audacieux. Ainsi, on peut s’attendre à une évolution plus importante du modèle de projet (POM). La compatibilité au niveau du repository continuera d’être assurée avec les clients Maven 2.0.

Afin de pouvoir continuer à capitaliser sur la masse importante de code réalisé pour Plexus, une extension pour Guice a été développée pour assurer l’intégration des composants Plexus historiques dans le conteneur Guice.

Aucune date n’est pour le moment indiquée pour cette version 3.1.

M2Eclipse et Nexus

M2Eclipse, le plugin Eclipse qui apporte le support de Maven à Eclipse, sort de sa gestation et va bientôt être finalisé. Jason van Zyl assure que les nombreux problèmes de stabilité et de comportement avec les gros projets Maven sont corrigés. L’intégration plus poussée à l’IDE que permettra Maven 3.0 devrait elle aussi améliorer l’ergonomie de ce plugin.

Nexus, pour sa part, va lui aussi abandonner Plexus au profit de Guice et Peaberry. Cette migration interviendra d’ailleurs en premier sur Nexus, Maven 3.1 suivra.

Conclusion

Maven est en général un sujet sulfureux dans la communauté Java. Son leader, Jason van Zyl, ne fait lui même pas l’unanimité et sa présentation a été diversement appréciée.

Malgré tout, il faut bien reconnaître que les chantiers engagés sur Maven sont cette fois bien réels. Les démonstrations faites se sont montrées convaincantes, même si seule la mise en œuvre pratique permettra de juger de cette nouvelle version.

On regrettera tout de même le peu d’information actuellement disponible sur Maven 3 en dehors de quelques billets sur le blog de Sonatype.

Revue de Presse Xebia

Xebia France — Mon, 12 Oct 2009 16:41:35 +0000

La revue de presse de l’actualité Java/J2EE hebdomadaire proposée par Xebia.

Actualité éditeurs / SSII

RIA

Le coin de la technique

Actualité éditeurs / SSII

La fondation Eclipse se prépare à Servlet 3.0 avec Jetty 7.0

La fondation Eclipse nous livre une nouvelle version de Jetty estampillée 7.0. Côté nouveauté, pas grand chose à vrai dire. Il y a évidemment l’habituelle série de corrections de bugs et d’améliorations de performance. Cette nouvelle version marque surtout le début de la route vers l’implémentation des servlets 3.0 prévue pour Jetty 8.0. C’est aussi l’occasion pour Eclipse d’assimiler un peu plus le projet en changeant principalement le package ancêtre de org.mortbay vers org.eclipse, gare au refactoring donc. A noter tout de même, Jetty est maintenant livré sous une forme modulaire pleinement compatible OSGI. Webtide en profite pour livrer la même version de Jetty, en y intégrant des modules additionnels:

JSP de glassfish
JTA d’atomikos
plugin maven
integration d’ant
configuration Spring

Jetty 6 sera encore maintenu pendant quelques temps (aucune précision de la part d’Eclipse), tous les nouveaux développements seront faits sur Jetty 7, et la branche 8 sera en pré-release dans les prochains mois et supportera l’API Servlet 3.0.

Sonar 1.11

SonarSource nous gratifie d’une version 1.11 du désormais célèbre outil de suivi de qualité Sonar. Comme souvent, de nombreux de bugs ont été corrigés. Parmi les améliorations, on peut noter les passages à Hibernate 3.3 et GWT 1.7. Au chapitre des nouvelles fonctionnalités, la possibilité de réutiliser les fichiers de configuration PMD et CheckStyle définis dans le pom permettra de plus aisément éviter les doublons.

SonarSource tente de faciliter la vie des développeurs de plugins avec l’apparition d’un archétype Maven pour créer des plugins Sonar. D’autres nouveautés d’API, comme le filtrage de widgets suivant différents critères (comme le rôle utilisateur ou la langue choisie), ajoutent de la flexibilité.

L’annonce sur le blog Sonar avec plein de jolies images.
La release note.

RIA

Air ‘Athena’

Non, ce n’est pas une nouvelle marque de baskets, mais, comme les flexeurs le savent depuis le Flash Camp de mai, le nom de code de la future version de Adobe Air, la version 2.0. Comme on s’y attendait, celle-ci fonctionnera avec Flash 10 et Flex 4. Même si aucune date officielle n’a été avancée, Adobe dévoile peu à peu les principales évolutions de sa plate-forme, nouveautés répertoriées par Elad Elrom sur InsideRIA.
Commençons par celle qui nous semble vitale dans l’adoption de AIR / Flex à grande échelle, à savoir une amélioration drastique des performances. Les équipes d’Adobe ont mis l’accent sur la réduction des ressources (CPU et mémoire) consommées par le runtime AIR. Les tests effectués sur une mini application montrent en effet une diminution des ressources utilisées (en regard de la version 1.5). Reste à tester ces optimisations sur une application gourmande… Toujours au chapitre performance, Adobe promet une optimisation de Webkit (le browser open source embarqué par AIR) et une installation Linux native.
Au menu des nouveautés, nous avons :

Une meilleure connaissance de la plate-forme matérielle, avec la gestion des devices multi-touch et la gestion des périphériques de stockage USB ou réseau ‘à chaud’.
Un enrichissement des fonctionnalités des APIs existantes : points de sauvegarde dans les transactions, support IPv6, augmentation de la taille maximale de la fenêtre AIR, manipulation des données de l’API Microphone, time-out d’inactivité…
De nouvelles fonctionnalités via de nouvelles API, dont la plus étonnante est l’API File promises. Celle-ci permet de télécharger en local, depuis une application AIR, un ensemble de fichiers par simple Drag & Drop. D’autres API font également leur apparition, en particulier au niveau du support réseau et de l’adhérence de AIR à l’OS (les fichiers peuvent maintenant être ouverts par des processus natifs de l’OS, par exemple Notepad pour un .txt sous Windows).

Une évolution assez naturelle donc (correction des gros points de blocage des versions précédentes), mais quelques promesses de fonctionnalités intéressantes, en particulier via l’adhérence à l’OS.

DHTMLX 2.5

Des nouvelles de DTHMLX (la 11ème librairie de notre revue de presse de fin janvier dernier) qui est sorti il y a quelques semaines en version 2.5.

Cette release apporte plusieurs corrections et améliorations sur tous les composants de la suite. On retiendra plus particulièrement :

Une API orientée objet (l’API fonctionnelle est toujours disponible) ,
Nouvelle skin par défaut avec d’ici peu (mais non présent dans cette release) un Skin Customizer qui permettra de modifier facilement les couleurs principales du thème standard,
Nouveau moteur de rendu qui améliore la performance d’affichage des composants Layout, Windows, Accordion et Tabbar,
Une API de conteneurs unifiée (toujours pour les Layout, Windows, Accordion et Tabbar),
Améliorations générales pour les composants Grid, Tree et TreeGrid,
Révision complète du DocsExplorer.

Puisque nous sommes sur DHTMLX, notons aussi le composant Scheduler v.2.0, sorti en juillet dernier, qui n’est pas inclus dans la suite mais qui vaut tout de même le détour si vous avez besoin d’un composant calendrier haut niveau.

Les téléchargements se passent par ici et comme d’habitude vous aurez le choix entre le téléchargement composant par composant ou le téléchargement de la suite complète.
Chaque composant existe en édition standard ou professionnelle. Pour résumer la version standard contient moins de fonctionnalités et est sous licence GPL alors que la professionnelle contient toutes les fonctionnalités, un support prioritaire en cas de bugs/questions sur le forum et plusieurs centaines d’exemples de fonctionnalités avancées.
Pour le détail des licences et des différents prix proposés pour les composants et pour la suite complète, cela se passe sur cette page.

Tips and Tricks Maven 2

Sonatype nous présente ici quelques nouveautés intéressantes de maven disponibles depuis la version 2.1 concernant les projets multi-modules. Cela se traduit par de nouvelles commandes disponibles telles que:

-rf, -resume-from: permet de spécifier au maven reactor le projet à partir duquel on veut reprendre le build
-pl, -projects: permet de sélectionner une liste de modules d’un projet multi-modules
-am, -also-make: combinée avec l’option -pl, elle permet de construire tous les modules dépendants du module passé à l’option pl
-amd, -also-make-dependents: combinée avec l’option -pl, elle permet de construire tous les modules qui ont une dépendance vers le module passé à l’option pl

Très bonne nouvelle donc pour les développeurs dont le build prenait beaucoup de temps à cause de la reconstruction de modules non modifiés (et non impactés) par leurs nouveaux développements.

Le coin de la technique

Sécurité : 5 choses de plus que les agresseurs d’applications web ne vous diront pas

Le Denim Group continue sa série 13 Things a Web Applications Attacker Won’t Tell You que nous avions traitée la semaine dernière avec 5 nouvelles failles de sécurité de nos applications web :

Ce n’est pas parce que vous utilisez un framework de sécurité que votre application est sécurisée.
Je n’utilise pas un browser pour attaquer votre application web.
J’adore quand votre site me permet d’uploader des fichiers dans l’arborescence des répertoires servis par l’application web.
Je peux intercepter et voler toutes les informations qui passent sur HTTP si elles ne sont pas protégées par SSL ou un mécanisme équivalent.
Une sécurité obscurantiste n’en est pas une (ne pas savoir faire ou se dire que ca n’arrivera pas ne protège pas).

Si le dernier point est un débat éternel chez les experts de la sécurité les premiers sont en revanche communément admis.

Les optimisations du JDK 6u14 activées par défaut sur le JDK 7

Rémi Forax, un contributeur sur OpenJDK et sur la JSR-292, a fait part de son étonnement en constatant un gain significatif de performance entre deux builds successifs de l’OpenJDK 7 actuellement en cours de développement. C’est ainsi qu’il a pu se rendre compte que deux optimisations majeures du compilateur JIT de la JVM étaient activées par défaut depuis le build 72 du projet : l’escape analysis et la compression de pointeurs. Celles-ci étaient apparues dans le JDK 6u14 mais n’y étaient pas activées par défaut.

Pour rappel l’escape analysis consiste en l’analyse du bytecode d’une méthode pour découvrir les références vers les objets qui ne « s’échappent » pas du contexte de la méthode. Grâce à cette analyse, la JVM peut alors décider d’allouer ces objets directement sur la stack plutôt qu’en heap comme c’est normalement le cas. Il en résulte un gain de performance évident puisque le coût d’allocation et de libération de mémoire est alors supprimé pour ces objets.

La compression de pointeurs, quant à elle, concerne uniquement les JVM 64 bits. En effet le passage d’un adressage de 32 à 64 bits entraîne une consommation plus élevée de la mémoire du fait de l’augmentation de la taille des pointeurs, induisant elle-même des temps de chargement plus longs et une surconsommation du cache du processeur. Pour palier ce problème, la compression de pointeurs se base sur le fait que la JVM aligne l’adresse des objets sur 64 bits (ceci afin de simplifier et donc d’accélérer leur accès en mémoire), pour procéder à un scaling des pointeurs. Ainsi, en limitant l’espace mémoire adressable à 32 Go, il est possible de contenir un pointeur dans 32 bits et donc de revenir à une consommation mémoire proche de celle d’une JVM 32 bits.

L’activation par défaut de ces deux optimisations sur le JDK 7 montre que l’équipe du projet estime désormais qu’elles ne sont plus expérimentales et qu’elles conviennent dans la majorité des cas. Ismael Juma précise par ailleurs qu’il est possible que ces activations par défaut soient reportées également au JDK 6 courant 2010.

Lumière sur JTestR

Aurélien Maury — Fri, 02 Oct 2009 12:09:59 +0000

Parmi les tâches incontournables de la vie d’un développeur, il y a l’écriture des tests unitaires. De nombreux outils tentent de nous faciliter la vie sur ce point. Aujourd’hui, je vais vous parler de JTestR, un framework de tests unitaires qui apporte la puissance et la rapidité d’écriture du scripting Ruby pour tester des applications Java. Lancé par Ola Bini, un contributeur incontournable du projet JRuby, JTestR est directement intégrable avec Ant, Buildr et Maven 2. Ce projet n’est pas encore très répandu, mais il apporte des avantages qui méritent d’être étudiés.

Tour d’horizon

JTestR est un ensemble de librairies Ruby dédiées aux tests, alliées à JRuby pour permettre un démarrage rapide et sans douleur de l’écriture des tests. L’un des atouts principaux du scripting est la rapidité d’écriture, et Ruby est un langage de scripting devenu très populaire ces dernières années, notamment grâce à Ruby on Rails. Les tests unitaires et d’intégration font partie intégrante du monde Ruby et plusieurs outils ont vu le jour pour les faciliter. JTestR embarque les librairies de test Ruby suivantes :

Test/Unit
RSpec
Expectations
Dust
Mocha

En tant qu’outil Java, il permet également des interactions avec les frameworks :

JUnit
TestNG

Dans sa dernière version, JTestR nécessite l’utilisation de Java 1.6.

Intégration

Livré sous la forme d’un jar avec une tâche Ant, il est facilement intégrable dans un projet existant. Une fois le jar disponible dans votre classpath, il suffit d’ajouter une balise taskdef à votre build.xml pour plus de confort et le tour est joué:

Pour les projets Maven, une modification mineure du pom.xml fera l’affaire :


  
    org.jtestr
    jtestr
    0.4.0
    
      src/test/ruby
    
    
      
        
          test

La directive de configuration tests permet de spécifier le répertoire dans lequel chercher les scripts de tests. Pour conserver l’esprit Maven, je vous conseille de créer un répertoire src/test/ruby et d’y placer tous les tests. La hiérarchie en sous répertoires pour représenter les packages des classes à tester ne pose pas de soucis.

Rédaction des tests

JTestR offre plusieurs possibilités pour la rédaction des tests. Tout d’abord, l’utilisation du framework de tests académiques de Ruby :Test::Unit. Cela n’apporte pas de grande nouveauté par rapport aux classiques tests JUnit. Le couteau suisse de méthode assert est disponible de la même façon.

Exemple de Test::Unit

class HashMapTests < Test::Unit::TestCase
  def setup
    @map = java.util.HashMap.new
  end
  def test_that_map_is_empty
    assert @map.isEmpty
  end
  def test_that_it_returns_a_keyset_that_returns_an_iterator_that_throws_exception
    assert_raises(java.util.NoSuchElementException) do
      @map.key_set.iterator.next
    end
  end
end

Mais il est également possible d’utiliser RSpec. Ce framework de tests est orienté « spécification » et propose une notation originale qui tend à rapprocher la rédaction des tests de la spécification du comportement attendu. La notation comparée :

# avec Test::Unit
assert_equals(result, 42)
# avec RSpec
result.should == 42

On se rapproche ainsi du langage naturel. En anglais dans le texte, certes, mais on se rapproche. La structure d’un fichier RSpec complet donne par exemple :

import java.util.HashMap
describe "An empty", HashMap do
  before :each do
    @hash_map = HashMap.new
  end
  it "should not be empty after an entry has been added to it" do
    @hash_map.put "foo", "bar"
    @hash_map.should_not be_empty
  end
  it "should be empty" do
    @hash_map.should be_empty
    @hash_map.size.should == 0
  end
  it "should return a keyset iterator that throws an exception on next" do
    proc do
      @hash_map.key_set.iterator.next
    end.should raise_error(java.util.NoSuchElementException)
  end
end

Il est possible de mixer dans le même projet des tests Test::Unit et des tests RSpec. Le respect d’une norme de nommage des fichiers suffit à JTestR pour déterminer le framework ciblé.

Une précision importante sur un point obscur dans la documentation : la commande import cherche dans les packages commençant par java, javax, org et com. Pour tous les autres il faut écrire :

import Java::fr.votre.package.VotreClasse

Limitations

Un problème qui peut être pointé du doigt est le temps de chargement de l’environnement JRuby. L’interpréteur prend en effet parfois plus de 10 secondes à se lancer. Pour pallier ce problème, JTestR possède un mode serveur qui permet de conserver en tâche de fond un serveur avec l’environnement JRuby en attente des tests à lancer. On supprime ainsi facilement le temps de chargement.

L’apprentissage des bases du langage Ruby peut également rebuter, mais c’est un obstacle faible dans la mesure où c’est un langage entièrement objet et où l’on manipule majoritairement les classes Java du projet à tester. Le pas est généralement franchi assez facilement.

Conclusions

L’offre de frameworks de tests est déjà conséquente dans le monde Java. JTestR n’est pas très répandu à l’heure actuelle. Malgré cela, l’utilisation de RSpec pour la rédaction des tests permet de rester proche d’une formulation verbale des comportements attendus. Dans une démarche TDD, cela peut être avantageux. On aura ainsi tendance à éviter de se perdre dans des formulations techniques dès les premières phases du projet.

De plus, je prendrai sérieusement en considération JTestR si j’avais des développeurs Ruby dans mon équipe. Le framework vous offre une chance de casser la frontière entre vos équipes Ruby et Java. L’aspect très concis des tests les rend lisibles autant par les développeurs Java que Ruby et renforce l’entraide entre équipes. Cela facilite la distribution des compétences et des connaissances entre développeurs, ce qui n’est jamais une mauvaise chose.

Ressources :

Traduction du Maven Definitive Guide, première relecture publique

Erwan Alliaume — Wed, 30 Sep 2009 04:39:50 +0000

Comme certains le savent déjà, je participe à la traduction française du Maven: The definitive Guide. La version originale, qu’il est possible de consulter ou de télécharger gratuitement, est portée par Sonatype, l’entreprise dont le fondateur et CTO est Jason van Zyl, l’un des pères du projet Maven. D’autres traductions ont été effectuées ou sont en cours, les versions allemande et chinoise sont déjà disponibles. Notez qu’il s’agira de la traduction officielle, elle sera rendue disponible a minima sur le site de Sonatype en version en ligne et par PDF et nous envisageons également une version imprimée.

Dans ce cadre, comme nous venons de terminer la partie 1 qui représente la première moitié du livre, nous lançons un premier appel public aux relectures. Le projet est hébergé sur github, il vous est donc tout à fait possible d’y participer à votre guise ou de venir consulter son avancement. C’est peut-être pour vous l’occasion de contribuer à un projet Open Source Maven … sans code … mais avec des développeurs dedans : l’Open Source ce n’est pas fait que de développement

Pour ceux qui seraient intéressés, voici quelques recommandations :

Il est préférable de nous contacter avant de vous lancer dans la relecture, nous pourrons ainsi répartir uniformément les relectures et éviter les corrections parallèles.
Privilégiez les versions HTML ou PDF pour la relecture, pour ne pas être gêné par la multitude des balises XML dont le format docbook est si friand.
N’hésitez pas à vous inscrire à la ML du projet (maven-guide-fr-subscribe AT sonatype.org).

Pour démarrer :

Build journalier de la traduction ;
Sources de la traduction sur notre projet GitHub ;
Créez un compte sur github pour pouvoir nous soumettre vos retours via l’Issue Tracker et télécharger la version XML du docbook.

N’hésitez pas à contacter l’un des membres de l’équipe pour toute question (mon adresse email : erwan DOT alliaume AT gmail.com).

Bonne (re)lecture

CITCON Paris 2009

Emmanuel Servent — Mon, 21 Sep 2009 11:34:26 +0000

Le CITCON (prononcé « KITCON ») a eu lieu vendredi et samedi dernier à Paris, pour la session européenne 2009. Vendredi soir, après les présentations d’usage, l’open space a commencé par le remplissage du tableau des sessions par les fameux post-it. Pour rappel, les participants écrivent un thème sur un post-it et le collent n’importe où sur le tableau. C’est autour d’un verre, et entre deux discussions, qu’on vote et place les post-it dans les cases proposées pour chaque session.

Samedi matin, j’ai assisté à la session sur la gestion de source dans un environnement distribué. Après une mise au point sur la différence entre gestion de configuration et gestion de source, nous avons entamé la discussion sur l’outil très utilisé dans le développement Open Source dénommé GIT. Cet outil fonctionne en mode décentralisé : il n’y a pas un unique serveur de sources, mais chaque développeur fonctionne à la fois en mode serveur et en mode client. Le développeur peut, par exemple, versionner très souvent ses sources sur son serveur local, mais décider de ne valider ses changements qu’en une seule fois sur le serveur de référence (il peut même signer sa validation !).
Le cas d’un projet partagé entre la France et l’Australie m’a particulièrement intéressé. Le responsable avait mis en place un serveur intermédiaire GIT sur chaque site pour éviter les échanges réseau trop nombreux avec un serveur central. Une synchronisation régulière permettait aux deux sites d’être à jour. Il s’était rendu compte au bout d’un certain temps que cela était en réalité inutile, car la qualité du réseau faisait qu’on pouvait se permettre de n’avoir qu’un seul serveur. En revanche, si cela est peut-être vrai pour l’Australie, ce ne l’est pas forcément pour tous les pays.
Avec GIT, chaque copie du repository est une nouvelle branche ; un développeur en local, c’est une branche. Le fonctionnement des branches est un vrai casse-tête pour des outils comme Subversion, et cette approche propose finalement un peu de simplicité. Mais pour le moment, les serveurs d’Intégration Continue ne font pas la différence entre modes centralisé et décentralisé. Rien n’est proposé aujourd’hui pour mieux profiter d’un monde distribué…

Après un ravitaillement en café et jus d’orange, j’ai suivi Vincent Massol, de XWiki pour savoir comment améliorer notre façon de faire une release avec Maven. Arnaud Heritier faisait parti de la session et après une présentation du processus pour XWiki, ils ont démarré le codage d’une extension au plugin dependency. L’objectif était d’ajouter un goal pour récupérer les différences entre les versions des dépendances entre deux releases. Il faudra être attentif aux prochaines sorties de ce plugin, il y aura peut-être une nouvelle fonction.
Le constat, finalement, était qu’il y avait encore beaucoup d’étapes manuelles lors de la release d’une version et qu’à part développer ses propres MOJOs, Maven était assez loin du compte. Mais ça avance comme le montre le plugin versions, dont Arnaud Heritier nous a vanté les mérites.

L’après-midi, trois sessions nous attendaient mais je souhaite ne parler que de la dernière sur la configuration et le déploiement, les autres étant déjà traitées sur différents blogs. Un problème récurrent se pose sur chaque projet, celui de la modification des valeurs selon l’environnement sur lequel on déploie. On utilise, par exemple, des fichiers de propriétés qui sont remplacés au moment du packaging. Si on s’est trompé dans les propriétés ou si la valeur n’est connue que de la personne qui déploie, il faut dézipper le fichier, changer la valeur et refaire le package. Bonjour la galère !
Deux ingénieurs de ThoughtWorks nous ont présenté leur petit dernier : Escape. Sous ce nom très commun se cache une application Java dans laquelle on peut sauvegarder les valeurs des propriétés de chaque application dans un environnement donné. Ces valeurs peuvent être cryptées. Pour y accéder, une simple interface REST permet d’interroger la base et de récupérer la valeur : l’url http://mymachine:8080/environnements/dev/citcon/city, par exemple, renvoie la valeur de city pour l’environnement de dev sur l’application citcon. Je trouve ce projet simple et efficace pour améliorer la gestion des propriétés de nos applications. La mise en œuvre demandera un peu d’effort pour disposer d’un serveur central mais cela en vaut certainement la peine pour s’affranchir de cette partie de la configuration.

La conférence s’est terminée par un tour des participants sur leur « AA moment » (ie. ce qu’ils ont préférés!) et une distribution de livres sur l’intégration continue.
J’en ai gagné un, écrit par Paul M. Duvall, qui était juste à côté de moi, et me l’a dédicacé. Et c’est aussi ce qui rendait cette journée franchement sympathique et réussie; mon « AA moment » a été de mettre enfin un visage sur des auteurs de blogs ou des contributeurs open source, et surtout pouvoir converser de visu.

Maven, jetty plugin et section mappée

Romain Maton — Wed, 10 Jun 2009 08:28:05 +0000

Comme de nombreux projets web, nous utilisons pour le développement le plugin Jetty pour maven afin de lancer rapidement l’application.

Tout s’est toujours bien passé jusqu’au moment où nous avons attaqué concrètement la partie cliente (avec ses feuilles de style, fichiers Javascript…). En effet, le problème survient lors de la modification à la volée de ces fichiers pour n’avoir qu’un rafraîchissement à effectuer dans notre navigateur (et pas un arrêt/relance du serveur).

Ainsi, à la sauvegarde, on obtient l’erreur suivante :

Il nous est alors impossible de sauvegarder le fichier, l’erreur fichier ayant une section mappée utilisateur ouverte apparaît.

En effet, le file locking, mécanisme de restriction d’accès aux fichiers par les utilisateurs / processus, pose problème sous Windows si l’on veut modifier ces fichiers.

Jetty monte en mémoire tous les fichiers statiques (html, css, js, …) et utilise pour cela une section mappée (memory mapped file) dans le cas d’un connecteur NIO (celui par défaut). Or, sous Windows, l’utilisation de ce segment de mémoire virtuelle provoque immédiatement un lock du fichier. Il devient donc impossible de modifier dynamiquement ces fichiers et nous sommes obligés de redémarrer notre Jetty pour prendre en compte toute modification.

Pour contourner ce problème, plusieurs solutions existent.

Changement de connecteur (NIO vers IO)

La plus simple et rapide est de modifier le connecteur par défaut (SelectChannelConnector) qui est de type NIO(contournement du problème mais après tout nous sommes en dev, pas besoin d’en faire des tonnes ).

Donc, dans notre pom.xml, nous allons modifier la configuration de notre maven-jetty-plugin en ajouter les quelques lignes suivantes :


   org.mortbay.jetty
   maven-jetty-plugin
   
      ...
      
         
            ...
         
      
      ...

Le contournement se situe au niveau de la balise connectors. Ainsi, on force Jetty à utiliser le SocketConnector au lieu du SelectChannelConnector par défaut. Ce connecteur non NIO n’utilisera pas de section mappée pour charger les fichiers statiques et pourra dès lors les modifier à notre guise sans redémarrer Jetty.

Webdefault.xml

L’autre solution, que l’on pourrait qualifier de plus officielle (car directement sur le site de codehaus) nous plonge dans le Jar pour modifier la configuration du fichier webdefault.xml (fichier chargé par Jetty avant le web.xml).

Ce fichier se trouve dans le Jar de Jetty (%M2_REPO%/org/mortbay/jetty/jetty/6.1.x/jetty-6.1.x.jar), au niveau du package org.mortbay.jetty.webapp. Il faut alors trouver la balise servlet où l’on peut lire

Cela tombe très bien, c’est exactement notre problème . Nous pouvons donc passer cette valeur à false dans le fichier webdefault.xml pour ne pas utiliser cette fonctionnalité :


   ...
   
      useFileMappedBuffer
      false
   
   ...

Il ne reste plus qu’une dernière manipulation : dire au maven-jetty-plugin d’utiliser notre fichier de configuration webdefault.xml. Ces quelques lignes feront ce travail (avec votre fichier au niveau de src/main/etc) :


   org.mortbay.jetty
   maven-jetty-plugin
   
      ...
      src/main/etc/webdefault.xml
      ...

Voilà donc un gain de productivité qui ne se refuse pas !

Maximum Maven

Aurélien Maury — Thu, 30 Apr 2009 16:28:52 +0000

Maven, le célèbre outil de management de build de projet, est souvent considéré comme difficile d’approche. Le principal point rebutant, souvent mis en lumière, est la complexité de gestion des fameux fichiers pom.xml, qui décrivent les processus de build. Pour se motiver, il est important de se souvenir que, parmi ceux qui ont pris le temps de s’y intéresser, bien rares sont ceux qui font demi-tour. Comme en code, il existe des bonnes pratiques qui, si elles sont respectées, permettent de s’y retrouver facilement.

La route est longue mais la voie est libre. Voyons donc ensemble quelques règles de bonne conduite pour conserver des pom.xml maintenables et faire durer la lune de miel avec Maven.

Utilisez un artifact repository

Dès que vous travaillez avec Maven sur un véritable projet, c’est la première chose à faire. Un classique est d’utiliser Nexus, le dépôt open source de Sonatype. Avoir un dépôt en réseau local accessible par tous les membres de l’équipe présente de multiples intérêts :

Accélérer le téléchargement des dépendances : grâce au proxy-cache.
Maitriser les dépendances accessibles aux développeurs : on peut appliquer sur le proxy des politiques d’accès aux dépendances et ainsi les restreindre finement. Une règle serait, par exemple, d’interdire de dépendre d’un quelconque morceau de code licencié GPL, pour éviter la contamination de votre projet.
Déployer et rendre disponibles nos propres artefacts à nos équipes : en bout de chaine d’intégration continue, en déployant les artifacts sur le repository, on peut faire reposer des projets annexes sur des versions maitrisées de nos librairies.
Centraliser la gestion des repositories sur lesquels on s’appuie : dans l’administration de Nexus, on ne gère plus que la liste des repositories chez qui on récupère nos dépendances et on évite de polluer nos pom.xml avec ces considérations.

Pour bien commencer, Sonatype fournit un guide très complet sur l’installation et l’usage de Nexus : Repository Management with Nexus. Bien entendu, vous pouvez également vous tourner vers Apache Archiva ou encore Artifactory pour répondre aux mêmes besoins.

Déclarez toutes vos dépendances directes

Pour améliorer la maintenabilité des pom.xml, il est utile d’avoir sous les yeux les dépendances sur lesquelles vous vous appuyez. Derrière ce conseil qui parait évident se cache un risque d’erreur non négligeable.
Si vous déclarez ces dépendances :


	 
	 ch.qos.logback
	 	 logback-classic
	 	 0.9.15
	 
	 
	 	 org.springframework
	 	 spring-jdbc
	 	 2.5.6

le mécanisme de gestion des dépendances transitives de Maven (merci à lui) vous fournira toutes celles ci :

On pourrait s’arrêter là. Cependant, à ce stade, notre pom.xml ne permet pas de se rendre bien compte des librairies sur lesquelles nous nous appuyons réellement. Dans l’exemple ci-dessus, il est possible que du code de notre projet lance des appels directement sur spring-core. Cela ne pose pas de problèmes ni à la compilation, ni au build, mais, pour pouvoir gagner en lisibilité sur notre pom.xml, Maven nous a gratifié d’un plugin très utile : dependency:analyze, qui va lister toutes les librairies qui sont des dépendances directes pour notre projet.

$ mvn dependency:analyze
...
[INFO] [dependency:analyze]
[WARNING] Used undeclared dependencies found:
[WARNING]    org.slf4j:slf4j-api:jar:1.5.6:compile
[WARNING]    org.springframework:spring-core:jar:2.5.6:compile
[WARNING] Unused declared dependencies found:
[WARNING]    ch.qos.logback:logback-classic:jar:0.9.15:compile
[WARNING]    ch.qos.logback:logback-core:jar:0.9.15:compile

Les Used undeclared dependencies sont toutes les dépendances que nous pouvons ajouter à notre pom.xml pour en améliorer sa lecture et donc sa maintenabilité. Faites attention cependant, car ces dépendances sont des dépendances à la compilation. Les librairies listées dans les Unused declared dependencies peuvent très bien être des dépendances au runtime, auquel cas elles doivent rester en place.

Utilisez des propriétés partout où cela est possible

Je vous recommande d’utiliser autant de propriétés que possible dans le pom.xml. Par exemple, n’hésitez pas une seconde entre ce pom:


  
    ch.qos.logback
    logback-classic
    0.9.15
  
  
    org.springframework
    spring-jdbc
    2.5.6
  
  
    org.springframework
    spring-core
    2.5.6

et celui là:


  0.9.15
  2.5.6



  
    ch.qos.logback
    logback-classic
    ${logback.version}
  
  
    org.springframework
    spring-jdbc
    ${spring.version}
  
  
    org.springframework
    spring-core
    ${spring.version}

La deuxième version vous permettra de placer toutes vos propriétés en évidence en haut de votre fichier pom.xml et ainsi d’avoir en un rien de temps, sous les yeux, toutes les versions de vos dépendances. Encore une fois, l’objectif est ici de gagner du temps dans la manipulation de vos fichiers. Comme en code Java, il est toujours préférable de gérer une variable et d’en changer la valeur, que d’aller modifier tous les paramètres constants qui traîneraient dans le code.

Utilisez les profils

Il est courant d’avoir des opérations différentes à faire selon la machine sur laquelle on souhaite construire ou installer un projet. En effet, des informations telles que :

l’adresse d’un serveur de base de données
le niveau de log a utiliser
le reporting à générer lors du build

diffèrent selon l’environnement (machine de dev, serveur de qualification, de pré-prod, etc.). Pour répondre à ce besoin, Maven propose d’utiliser le mécanisme de profil de build. Ne vous en privez pas.

A l’intérieur d’un profil, vous pouvez surcharger les propriétés que vous injectez dans les fichiers properties, les plugins associés aux phases de build, les rapports à générer… Bref, pratiquement tout ce que vous pouvez inscrire dans un pom.xml est surchargeable dans un profil.

On peut activer les profils souhaités en utilisant l’option -P du binaire mvn :

mvn clean package -P monProfileTest,monProfilDev,monProfilReportingVerbeux

En complément, les profils Maven peuvent être configurés pour une activation automatique en fonction d’un ou de plusieurs paramètres tels que :

la version du JDK détectée
la présence ou l’absence d’un fichier dans l’arborescence du projet
le type et/ou la version du système
l’architecture du processeur
la valeur d’une propriété présente dans le pom.xml

Si vous utilisez ce genre d’activation automatique, il est toujours utile de se souvenir de l’existence de certains plugins fournis :

help:active-profiles : vous donne la liste des profils actifs pour votre configuration.
help:effective-pom : effectue la consolidation de la hiérarchie des pom.xml dans le cas d’héritage ou de modules, et vous affiche le pom.xml résultant. C’est ce pom.xml consolidé qui est utilisé par le binaire mvn lorsqu’on lance un build.

Réfléchissez bien au découpage de vos artefacts

Vaut-il mieux faire un projet avec des modules ou faire des projets séparés interdépendants ? Cette question est certainement une des plus génératrice de débat. Il n’existe pas de règle à proprement parler, cela dépend surtout de l’utilisation que vous comptez avoir de vos morceaux de code. Il est tout à fait possible d’appliquer une séparation de responsabilité stricte du genre :

un projet GUI, par exemple application web
… qui dépend d’un projet couche business
… qui dépend d’un projet couche dao
… qui dépend d’un projet model

Si on souhaite avoir de multiples implémentations de nos couches business et dao, on peut pousser encore le découpage en créant des projets contenant uniquement les interfaces et spécifier dans nos pom.xml l’implémentation qui nous intéresse. Cela nous donnerait quelque chose du genre :

un projet application web
… qui dépend d’un projet couche business impl, lui-même dépendant d’un projet couche business api
… qui dépend d’un projet couche dao impl, etc.

A moins que nous n’ayons que peu de réutilisation dans d’autres équipes et qu’il faille juste ranger un peu notre code pour avoir des tests unitaires jouables sur chaque couche. On pourrait alors se contenter d’un projet avec un sous-module par couche.

La philosophie du KISS devrait vous éviter de verser dans des extrêmes inconfortables. Le point à retenir ici est de toujours prendre un temps de réflexion pour ce découpage, il est très structurant. En changer en cours de projet prend du temps pour éviter les régressions et les pertes de code.

Evitez de vous appuyer sur les préférences locales

Vous trouverez sans aucun doute sur le net beaucoup de conseils tournant autour du fichier settings.xml ou du fameux Super-POM. Ces fichiers font partie de l’installation de Maven sur votre poste local. Je trouve qu’il est dangereux de s’appuyer dessus, dans la mesure où ces fichiers ne sont, par définition, pas intégrés à votre gestionnaire de sources. Par conséquent rien ne garanti leur versionnage d’une machine développeur à une autre, et cela peut entraîner des comportement inattendus.

De plus, tout ce qu’on pourrait y mettre peut être glissé dans le fichier pom.xml de votre projet. Mon conseil donc : évitez-les.

Si par hasard vous étiez obligé de vous en servir, lors de l’écriture de vos pom.xml, souvenez vous bien qu’aucun héritage ne permet d’écraser la valeur d’une propriété définie dans le fichier settings.xml. S’il est présent et contient des directives, il aura raison.

Osez écrire des plugins

Il faut se souvenir que Maven est, avant tout, une machine à lancer des plugins. Il fournit certes un cadre d’exécution axé sur les builds de projet mais nous pouvons y ajouter les plugins qui nous plaisent sur n’importe quelle phase de build. Le développement de plugin est relativement bien documenté et nous permet d’ajouter des fonctionnalités à l’infini.

Si, en plus, vous avez suivi le premier conseil de cet article, vous pourrez déployer vos plugins sur le repository de votre réseau local et ainsi étendre facilement l’utilisation de vos plugins à travers vos équipes et vos projets.

Pour conclure

Nous n’avons vu ici que l’essentiel des pratiques permettant de mieux vivre son expérience Maven. Il existe beaucoup de bonnes pratiques et il est rarement possible de toutes les appliquer en même temps tellement cet outil est flexible. La meilleur méthode est sûrement de bien réfléchir à votre environnement, vos besoins, et à votre utilisation des projets que vous gérez. Une fois ceci fait, vous pourrez édicter vos propres bonnes pratiques, et les faire connaître et appliquer à vos équipes de développement sur le long terme.

Pour approfondir :