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