Redfish's Blog

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

noreply@blogger.com (redfish4ktc) — Wed, 14 Dec 2011 07:30:00 +0000

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

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

noreply@blogger.com (redfish4ktc) — Fri, 09 Dec 2011 07:47:00 +0000

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

noreply@blogger.com (redfish4ktc) — Thu, 29 Sep 2011 05:30:00 +0000

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

noreply@blogger.com (redfish4ktc) — Thu, 14 Jul 2011 09:31:00 +0000

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>

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

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

noreply@blogger.com (redfish4ktc) — Tue, 12 Oct 2010 15:38:00 +0000

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 :

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

noreply@blogger.com (redfish4ktc) — Mon, 30 Aug 2010 11:21:00 +0000

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.

multiple PuTTY instances

noreply@blogger.com (redfish4ktc) — Wed, 21 Jul 2010 14:26:00 +0000

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

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

noreply@blogger.com (redfish4ktc) — Fri, 16 Apr 2010 15:20:00 +0000

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

m2eclipse : version 0.10 disponible

noreply@blogger.com (redfish4ktc) — Mon, 15 Feb 2010 15:16:00 +0000

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.

Keljob : évolutions de la home en 2009

noreply@blogger.com (redfish4ktc) — Wed, 20 Jan 2010 10:44:00 +0000

Une petite vidéo de 27s qui montre l'évolution de la home Keljob au cours de l'année 2009.

Evolution du site www.keljob.com de mars 2009 à janvier 2010. from Thomas Larzillière on Vimeo.

Maven 3.x - de plus en plus d'informations disponibles

noreply@blogger.com (redfish4ktc) — Fri, 06 Nov 2009 11:36:00 +0000

Maven 3.x est sur les rails depuis un petit bout de temps (avant il s'appelait 2.1.x avant la réorganisation des numéros de version, voir le post d'Arnaud Héritier en octobre 2008 sur le blog d'Octo)
Sans s'en rendre compte, on l'utilise tous les jours quand on a le plugin eclipse m2eclipse (via Maven Embedder).

Voici une petite sélection d'articles et présentations qui nous en apprennent un peu plus sur le futur de Maven :

une présentation par Arnaud Héritier (voir les slides de 63 à 67)
exemple de configuration avec des pom en groovy (maven devient polyglote)
une présentation par Jason Van Zyl sur les principaux changements dans Maven 3.x
Début d'un état des lieux sur les raisons qui ont menées à Maven 3.x

D'une manière générale, on nous vend Maven 3.x comme entièrement compatible avec les builds Maven 2.x (un gros effort à été fait sur les tests d'intégration pour valider la non régression).
Il ne me reste plus qu'à tester un snapshot de ce nouveau Maven sur Keljob pour être fixé.

A suivre.

RbUtils Wiki Now On MediaWiki

noreply@blogger.com (redfish4ktc) — Mon, 24 Aug 2009 11:34:00 +0000

Due to changes on sourceforge.net and its hosted applications, the wiki documentation of RbUtils has been moved from WikiSpaces to MediaWiki.
You can check it out at http://sourceforge.net/apps/mediawiki/rbutils/index.php?title=Main_Page

RbUtils 0.13 released

noreply@blogger.com (redfish4ktc) — Fri, 19 Jun 2009 09:30:00 +0000

RbUtils 0.13 is now released.
See the release notes for more information.

Keljob est sur Facebook

noreply@blogger.com (redfish4ktc) — Mon, 23 Mar 2009 18:39:00 +0000

Comme indiqué dans un article sur 01net, Keljob est désormais disponible sur Facebook sous forme d'application à destination des entreprises et des candidats.

Plus d'informations directement sur keljob.com.

RbUtils development status

noreply@blogger.com (redfish4ktc) — Thu, 12 Mar 2009 11:01:00 +0000

Developments of RbUtils 0.13 are done and we expect to release this version on March 2009.

RbUtils 0.13 contains the following changes:

html for rbchecker
html for rbgenerator
upgrade third party jars

Next release will focus on making extensions easier.

Welcome to my blog

noreply@blogger.com (redfish4ktc) — Fri, 27 Feb 2009 14:58:00 +0000

Welcome to my blog!

I use this blog to dump random thoughts (in French or English) about Java, RbUtils, Maven, Fitnesse and software development in general.