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
jeudi 21 mai 2009
jeudi 16 avril 2009
Comparaison des serveurs d'intégration continue
Si vous souhaitez comparer les différents serveurs d'intégration continue, voici deux liens utiles:
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/
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.
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
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.
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
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.
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.
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/
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:
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
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.
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.
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
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).
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!
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).
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).
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:
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).
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).
Inscription à :
Articles (Atom)