Wednesday, December 14, 2011

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


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



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

Friday, December 9, 2011

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

Thursday, September 29, 2011

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.

Thursday, July 14, 2011

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.

Tuesday, October 12, 2010

maven : accélerer les releases en ne générant pas le site

Maj du 14/07/2011 : la conf maven est affichée via un gist

Si comme nous sur keljob, vous ne souhaitez pas publier les sites des projets maven ni les générer (opération bien longue) au moment de la release, on a un moyen simple de configurer le maven-release-plugin.

Pour cela, on peut modifier les goals (ça ressemble plutôt aux phases du cycle de vie, mais c'est la terminologie utilisée dans la documentation du plugin) lancés au moment du release:perform de la manière suivante  :




Monday, August 30, 2010

maven-site-plugin : quelques bugs avec la version 2.1

Maj du 12/10/2010: j'ai supprimé de ce post la configuration qui permet de releaser sans deployer le site que j'ai remplacé par un lien vers le post dédié

Dernièrement sur keljob (courant juillet), on est passé à la version 2.1 du plugin et on a eu quelques surprises. Depuis la version 2.1.1 est sorti et les problèmes semble toujours là.
Heureusement, comme on va le voir, rien de bloquant.


Ca commence avec des messages de warnings intempestifs qui viennent polluer grandement les messages affichés par Maven :

[WARNING] Deprecated API called - not org.apache.maven.doxia.sink.Sink instance and no SinkFactory available.

Tout ceci est tracé dans MSITE-490. On attend le fix pour la version 2.2


Plus grave, il n'est plus possible de faire un site:deploy car la commande foire systématiquement à cause d'un problème de commons-logging. C'est particulièrement problématique avec la configuration standard du plugin de release qui déploie le site!!!!!

Un workaround est heureusement disponible sur MSITE-459. Il consiste a exclure la dépendance vers commons-logging qui pose problème.

Egalement possible, ne pas déployer le site au moment de la release.

Wednesday, July 21, 2010

multiple PuTTY instances

J'ai découvert dernièrement PuTTY Connection Manager qui permet de lancer des commandes sur plusieurs instance putty ce qui est bien pratique quand on doit faire la même opération sur plusieurs serveurs

Ca permet de faire un peu comme du cssh mais depuis un poste Windows.....

Friday, April 16, 2010

Les serveurs JIRA, Bugzilla, or Confluence de la fondation Apache ont été hackés

J'ai reçu un mail mardi 13/04/2010 qui me conseillait vivement de modifier mes mots de passe sur leur JIRA puisque la base (dont les mots de passe) avait été hackée voire copiée!!!!

Tout est sur ce post : https://blogs.apache.org/infra/entry/apache_org_04_09_2010

Monday, February 15, 2010

m2eclipse : version 0.10 disponible

On attendait depuis plus d'un an une version stable, c'est chose fait avec cette nouvelle version sortie aujourd'hui.
Au programme, principalement de meilleures performances et l'intégration de Maven 3.0 (comme c'était déjà le cas avec les dernières versions 0.9.9 de la branche de développement)

La documentation a été également mise à jour sur le site officiel du plugin. On peut se demander si le wiki ne va pas disparaître puisqu'il semble être remplacé par le site et le livre de référence.