Retours sur Keljob #1 : les serveurs d'intégration utilisés

Préambule : j'ai quitté l'équipe de développement de Keljob à Paris fin février 2011 (j'en faisais partie  depuis avril 2007) pour commencer une nouvelle vie à Grenoble. Cet article est le premier d'une série dans laquelle je reviens sur des aspects techniques, fonctionnels et humains de cette époque.


Tout à commencer en 2006 (je n'y étais pas, donc les infos données ici proviennent de ce que j'ai pu récupérer, en particulier en discutant avec Sven). A cette époque, l'ensemble du code est passé sous Maven 2 et une 1ère expérimentation a été faite avec Continuum.

En septembre 2007, on passe en agile, et on teste Hudson qu'on adopte définitivement. En 2010, on installe une instance pour les projets communs de la boîte et on envisage de passer toutes les instances en maître-esclave.

Je présente ici la liste de nos mises à jour où on peut voir certains échecs dus à l'instabilité d'Hudson.

Personnellement, j'ai toujours préféré avoir des releases fréquentes même si parfois on a des surprises; c'est ce qui fait la force du produit (avec ses plugins).
On le voit encore depuis le fork : Jenkins et ses releases hebdomadaires, quasiment tous les développeurs du core et des plugins qui ont rejoint le navire. De l'autre, la nouvelle équipe Hudson qui après avoir critiqué la stabilité et la gouvernance est bien seule (où sont les utilisateurs ?)

Pour ceux qui n'ont pas suivi l'histoire, je vous propose ces articles de

• http://blog.loof.fr/2011/02/hudson-et-jenkins-sont-dans-un-bateau.html
• http://blog.loof.fr/2011/05/hudsonjenkins-episode-v-lempire-contre.html

et en graphique (à noter que ces données proviennent de personne pro-jenkins) :

• http://www.slideshare.net/kohsuke/current-state-of-jenkins
• http://pelegri.wordpress.com/2011/06/06/jenkins-going-strong-4-months-after-split/

Après cette digression sur le fork, voici les dates d'installation des différentes versions.
Pour plus d'informations concernant les versions, voir le changelog actuel et le changelog passé

• 10/01/2011: Hudson 1.393
• 18/11/2010: Hudson 1.385
• 13/09/2010: Hudson 1.376
• 01/09/2010: Hudson 1.374
• 19/07/2010: Hudson 1.367
• 07/07/2010: Hudson 1.365
• 25/05/2010: Hudson 1.359
• 31/03/2010: Hudson 1.353
• 18/03/2010: Hudson 1.351
• 10/03/2010: Hudson 1.349
• 04/03/2010: Hudson 1.348
• 19/02/2010: Hudson 1.346
• 03/02/2010: Hudson 1.343
• 18/01/2009: Hudson 1.341
• 08/01/2009: Hudson 1.339
• 23/11/2009: Hudson 1.335
• 03/11/2009: Hudson 1.332
• 28/10/2009: Hudson 1.330
• 21/10/2009: Hudson 1.329
• 08/10/2009: Hudson 1.327
• 07/09/2009: Hudson 1.323
• 24/08/2009: Hudson 1.321
• 19/08/2009: Hudson 1.320
• 03/08/2009: Hudson 1.318
• 20/07/2009: Hudson 1.316
• 29/05/2009: Hudson 1.308
• 06/04/2009: Hudson 1.296
• 27/03/2009: Hudson 1.293
• 13/03/2009: Hudson 1.291
• 24/02/2009: Hudson 1.285
• 28/01/2009: Hudson 1.278
• 15/12/2008: Hudson 1.263
• 18/11/2008: Hudson 1.262
• 05/11/2008: Hudson 1.259
• 03/10/2008: Hudson 1.255 (j'ai dû supprimer un build de cvmail-core-nightly car le fichier build.xml ne pouvait pas être parsé)
• 07/08/2008: Hudson 1.245 (roolback en 1.232 car impossible de recharger certains build archivés)
• 01/08/2008: Hudson 1.242 (rollback en 1.232 car impossible de recharger certains build archivés sur keljob-spring-nightly en particulier)
• 25/07/2008: Hudson 1.237 (roolback en 1.232 car impossible de recharger certains build archivés)
• 04/07/2008: Hudson 1.232
• 22/04/2008: Hudson 1.210
• 09/04/2008: Hudson 1.206
• 21/03/2008: Hudson 1.199
• 18/03/2008: Hudson 1.197
• 05/03/2008: Hudson 1.185
• 19/02/2008: Hudson 1.184
• 11/02/2008: Hudson 1.183
• 05/02/2008: Hudson 1.180
• 17/12/2007: Hudson 1.161

Ant classpath Tip #2 : afficher les problèmes de classpath à la compilation

Pour ce tip, on va s'appuyer sur une option non standard du compilateur Oracle : -Xlint:path
Elle permet d'afficher des warnings sur des éléments déclarés au classpath mais que le compilateur n'arrive pas à trouver et qui du coup ne sont pas pris en compte.

J'ai trouvé cette option utile au moins pour les 2 cas suivants :

• on a un jar qui déclare des dépendances via le classpath de son fichier manifest, en particulier via des chemins relatifs
• détection des erreurs dans les chemins menant à un répertoire ou un jar qu'on déclare au classpath

La mise en oeuvre avec Ant est très simple.

<javac srcdir="${src.dir}" destdir="${classes.dir}"> 
  <classpath refid="core.classpath" /> 
  <compilerarg value="-Xlint:path" /> 
<javac>



Ça m'a bien aidé dans un contexte weblogic où $WL_HOME/modules/features/weblogic.server.modules_10.0.2.0.jar ne contient aucune classe et ne référence que des dépendances. Dans mon cas, une des dépendances manquait suite à une suppression involontaire dans mon installation weblogic
Le coupable en gras dans le Manifest qui suit. Ouf!


Manifest-Version: 1.0 
Class-Path: weblogic.server.modules.L10N_10.0.2.0.jar ../com.bea.core. 
 antlr.runtime_2.7.5.jar ../org.apache.ant.patch_1.6.5.1.jar ../org.ap 
 ache.ant_1.6.5/lib/ant-all.jar ../com.bea.core.apache.bcel_5.2.0.0.ja 
 r ../com.bea.core.repackaged.apache.bcel_5.2.0.0.jar ../com.bea.core. 
 apache.commons.collections_3.2.0.jar ../com.bea.core.apache.commons.l 
 ang_2.1.0.jar ../com.bea.core.apache.commons.pool_1.3.0.jar ../com.be 
 a.core.apache.dom_1.0.0.0.jar ../com.bea.core.apache.logging_1.0.0.0. 
 jar ../org.apache.openjpa_1.0.0.1.jar ../com.bea.core.apache.xml.secu 
 rity_1.3.0.jar ../com.bea.core.xml.xmlbeans_2.3.1.0.jar ../com.bea.co 
 re.logging_1.0.2.0.jar ../com.bea.core.bea.opensaml_2.0.0.0.jar ../co 
 m.bea.core.xml.staxb.buildtime_1.0.2.0.jar ../com.bea.core.xml.staxb. 
 runtime_1.0.2.0.jar ../com.bea.core.annogen_1.0.2.0.jar ../com.bea.co 
 re.kodo_4.1.3.1.jar ../com.bea.core.kodo.integration_1.0.1.0.jar ../c 
 om.bea.core.kodo.integration.tools_1.0.1.0.jar ../com.bea.core.proces 
 s_5.3.0.0.jar ../com.bea.core.xml.beaxmlbeans_2.3.1.0.jar ../com.bea. 
 core.repackaged.aspectj.aspectjweaver_5.0.0.jar ../com.bea.core.repac 
 kaged.apache.commons.logging_1.1.0.jar ../com.bea.core.repackaged.spr 
 ingframework.spring_2.0.2.jar ../com.bea.core.repackaged.springframew 
 ork.pitchfork_1.0.0.jar ../com.bea.core.common.engine.impl_2.0.2.0.ja 
 r ../com.bea.core.common.engine.api_2.0.2.0.jar ../com.bea.core.commo 
 n.security.api_2.0.2.0.jar ../com.bea.core.common.security.impl_2.0.2 
 .0.jar ../com.bea.core.common.security.jdkutils_2.0.2.0.jar ../com.be 
 a.core.common.security.utils_2.0.2.0.jar ../com.bea.core.common.secur 
 ity.providers.utils_2.0.2.0.jar ../com.bea.core.common.security.provi 
 ders.env_2.0.2.0.jar ../com.bea.core.apache.commons.net_1.4.1.jar ../ 
 glassfish.el_1.0.1.0_2-1.jar ../glassfish.jaxb_1.0.2.0_2-0-5.jar ../g 
 lassfish.jaxws.resolver_2.0.1.jar ../glassfish.jaxws.rt_1.0.1.0_2-0-1 
 .jar ../glassfish.jaxws.saaj.impl_2.0.1.jar ../glassfish.jaxws.sjsxp_ 
 2.0.1.jar ../glassfish.jaxws.tools_1.0.1.0_2-0-1.jar ../glassfish.sta 
 x.ex_1.0.0.jar ../glassfish.xmlstreambuffer_0.1.117.jar ../com.bea.co 
 re.apache.oro_2.0.8.jar ../javax.activation_1.1.jar ../javax.annotati 
 on_1.0.jar ../javax.interceptor_1.0.jar ../javax.ejb_3.0.jar ../javax 
 .jdo_2.0.jar ../javax.enterprise.deploy_1.2.jar ../javax.jms_1.1.jar 
 ../javax.jsp_1.0.1.0_2-1.jar ../javax.jws_2.0.jar ../javax.mail_1.4.0 
 .2.jar ../javax.management.j2ee_1.0.jar ../javax.persistence_1.0.1.0_ 
 1-0.jar ../javax.resource_1.5.jar ../javax.servlet_1.0.1.0_2-5.jar .. 
 /javax.transaction_1.1.jar ../javax.xml.bind_2.0.jar ../javax.xml.soa 
 p_1.3.0.0.jar ../javax.xml.stream_1.0.1.0_1-0.jar ../javax.xml.ws_2.0 
 .jar ../javax.xml.rpc_1.1.jar ../com.bea.core.apache.log4j_1.2.13.jar 
  ../monfox.dsnmp.agent_1.0.1.0_4-6-5.jar ../com.bea.core.jsafe_3.5.0. 
 jar ../com.bea.core.serp_1.12.0.jar ../com.bea.core.apache_1.0.1.0.ja 
 r ../com.bea.core.beangen_1.0.2.0.jar ../com.bea.core.beaninfo_1.0.1. 
 0.jar ../com.bea.core.datasource_1.0.2.0.jar ../com.bea.core.descript 
 or_1.0.3.0.jar ../com.bea.core.repackaged.asm_1.5.2.jar ../com.bea.co 
 re.diagnostics.core_1.0.1.0.jar ../com.bea.core.diagnostics.instrumen 
 tor_1.0.1.0.jar ../com.bea.core.i18n_1.0.1.0.jar ../com.bea.core.i18n 
 .generator_1.0.1.0.jar ../com.bea.core.management.core_1.0.1.0.jar .. 
 /com.bea.core.mbean.maker_1.0.1.0.jar ../com.bea.core.mbean.support_1 
 .0.1.0.jar ../com.bea.core.messaging.kernel_1.0.2.0.jar ../com.bea.co 
 re.resourcepool_1.0.2.0.jar ../com.bea.core.weblogic.rmi.client_1.0.1 
 .0.jar ../com.bea.core.weblogic.security.wls_2.0.2.0.jar ../com.bea.c 
 ore.weblogic.saaj_1.0.2.0.jar ../com.bea.core.weblogic.stax_1.0.2.0.j 
 ar ../com.bea.core.store_1.0.2.0.jar ../com.bea.core.store.gxa_1.0.1. 
 0.jar ../com.bea.core.transaction_2.0.2.0.jar ../com.bea.core.utils.f 
 ull_1.0.2.0.jar ../com.bea.core.utils.classloaders_1.0.1.0.jar ../com 
 .bea.core.utils.expressions_1.0.1.0.jar ../com.bea.core.utils.wrapper 
 _1.0.1.0.jar ../com.bea.core.timers_1.0.2.0.jar ../com.bea.core.weblo 
 gic.workmanager_1.0.2.0.jar ../com.bea.core.workarea_1.0.1.0.jar ../c 
 om.bea.core.jatmi_1.0.1.2.jar ../com.bea.core.weblogic.security_2.0.2 
 .0.jar ../com.bea.core.nodemanager.plugin_1.0.1.0.jar ../com.bea.core 
 .jmspool_1.0.2.0.jar 
Feature-Name: weblogic.server.modules

Ant classpath Tip #1 : afficher un classpath de manière lisible

Préambule : ces derniers mois, j'ai pas mal retravaillé avec Ant dans un contexte Weblogic. Je propose donc en commençant par ce post, une série de notes sur la problématique du classpath et de Ant



Supposons qu'on veuille afficher un classpath qu'on a précédemment défini dans Ant. Dans tout ce qui va suivre,  path.classpath.compile correspondra à l'identifiant du classpath qui doit être préalablement défini et qu'on veut afficher

On utilise habituellement quelque chose du genre :
<property name="echo.path.compile" refid="path.classpath.compile">
<echo level="info" message="${echo.path.compile}" /> 

Ce qui génère dans la console quelque chose du style (suivant l'os, le séparateur des éléments du classpath pourra être différent)


[echo] /tomcat/common/lib/jsp-api.jar:/tomcat/common/lib/ant.jar:/tomcat/common/lib/jmx.jar:/tomcat/common/lib/commons-collections-3.1.jar:/tomcat/common/lib/commons-dbcp-1.2.1.jar:/tomcat/common/lib/commons-el.jar:/tomcat/common/lib/commons-lang-2.1.jar:/tomcat/common/lib/commons-pool-1.2.jar:/tomcat/common/lib/tools.jar


C'est n'est vraiment pas très lisible, surtout dans le cas où on a beaucoup de jars (par exemple, avec l'ami Weblogic).
Du coup, ce serait par exemple plus clair d'avoir tous les éléments les uns en dessous des autres.


Cette problématique étant loin d'être nouvelle, je me suis complètement inspiré d'un post de 2005 intitulé  Pretty printing Java classpaths using Ant's pathconvert task qui détaille parfaitement la solution et sa mise en oeuvre.


Je reproduis ici telle quelle la solution proposée.

<!-- get the source compile classpath in a printable form -->
<pathconvert pathsep="${line.separator}|   |-- "
             property="echo.path.compile"
             refid="path.classpath.compile">
</pathconvert>

<echo message="|-- compile classpath"/>
<echo message="|   |"/>
<echo message="|   |-- ${echo.path.compile}"/>

[echo] |-- compile classpath
[echo] |   |
[echo] |   |-- /tomcat/common/lib/jsp-api.jar
[echo] |   |-- /tomcat/common/lib/ant.jar
[echo] |   |-- /tomcat/common/lib/jmx.jar
[echo] |   |-- /tomcat/common/lib/commons-collections-3.1.jar
[echo] |   |-- /tomcat/common/lib/commons-dbcp-1.2.1.jar
[echo] |   |-- /tomcat/common/lib/commons-el.jar
[echo] |   |-- /tomcat/common/lib/commons-lang-2.1.jar
[echo] |   |-- /tomcat/common/lib/commons-pool-1.2.jar
[echo] |   |-- /tomcat/common/lib/tools.jar
[echo] |   |-- ...

Si on souhaite factoriser cette technique pour l'utiliser à plusieurs endroits, on peut passer par un macrodef comme décrit dans un commentaire du même post que précédemment.

Affichage de code sur ce blog

Maj du 07/09/2011 :  ajout dans l'article de la visualisation du code affiché depuis le gist

Depuis le début, je me posais la question concernant l'affichage du code.
Dans un 1er temps, je l'affichais directement comme du texte mais ce n'était vraiment pas satisfaisant :

• pas de coloration syntaxique
• dès qu'il y avait du html, une fois sur 2, les balises n'étaient pas échappées
• j'en passe et des meilleures

Exemple (tiré de l'article maven : accélerer les releases en ne générant pas le site) :


<plugin>
  <artifactId>maven-release-plugin</artifactId>
  <version>2.0</version>
  <configuration>
    <!-- Only "deploy" instead of "deploy site-deploy" -->
    <goals>deploy</goals>
  </configuration>
</plugin>


Du coup, je me suis dit que j'allais faire comme tout le monde et utiliser SyntaxeHighlighter. Mais comme je suis fainéant, j'avais pas trop envie de modifier le thème de ce blog d'autant que j'aime bien le changer de temps en temps et je suis certain que j'aurais oublié de reporter l'import.

Donc j'ai décidé d'utiliser le service de github : mes gists.
En plus, pour chaque extrait de code, j'ai un repo git ce qui permet d'avoir en bonus l'historique des modifications.

Voilà ce que donne l'exemple précédent :


C'est quand même plus clair.