jeudi 21 mai 2009

Le blog déménage

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

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

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

dimanche 12 avril 2009

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

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

mercredi 4 mars 2009

Changement du repository snapshot de Maven

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

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

dimanche 15 février 2009

Intégration de Maven dans Eclipse

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

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

lundi 9 février 2009

Sortie de Sonar 1.6

Il vient de sortir la version 1.6 de Sonar

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

Il va falloir l'essayer le plus rapidement possible.

dimanche 8 février 2009

Nouvelle version du plugin Gradle de Hudson

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

vendredi 6 février 2009

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

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

jeudi 5 février 2009

Faire cohabiter le site Maven et Sonar

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

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

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

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

lundi 2 février 2009

Dashboard Hudson des projets Apache

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

samedi 24 janvier 2009

Gradle et gestion d'un proxy

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

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

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

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

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

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

samedi 17 janvier 2009

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

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

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

Hudson et le cloud computing

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

Suivez la discussion sur le sujet : ici

jeudi 15 janvier 2009

Plusieurs spécifications JEE6 sont sorties

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

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

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

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

Intégration continue et quelques problématiques

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

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

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

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

jeudi 8 janvier 2009

Mise en oeuvre de Ivy2 dans Hudson

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

Voici un exemple de mise en oeuvre.

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

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



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




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

Configuration du second projet



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

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

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


mercredi 7 janvier 2009

Gradle en version 0.5.1

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

lundi 5 janvier 2009

Nouvelle version du site MvnBrowser

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

Il vous suffit d’aller a la section “pom report”, puis de saisir l’exemple suivant:
<dependencies>
 <dependency>
   <groupId>org.jvnet.hudson.plugins</groupId>
   <artifactId>clearcase</artifactId>
   <version>0.8.1</version>
 </dependency>
  <dependency>
   <groupId>junit</groupId>
   <artifactId>junit</artifactId>
   <version>4.4</version>
   <scope>test</scope>
 </dependency>
 <dependency>
   <groupId>org.springframework</groupId>
   <artifactId>spring-core</artifactId>
 </dependency>
 <dependency>
   <groupId>log4j</groupId>
   <artifactId>log4j</artifactId>
   <version>1.2.15</version>
 </dependency>
</dependencies>

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




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




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