Continuum : envoyer le mail après le build dans tous les cas

Nous avons récemment installé et configuré Continuum. Comme nous démarrons avec, nous avons configuré nos projets pour recevoir systématiquement un mail lorsque le build est terminé, qu’il ait réussi ou non. Nous voulons en effet nous assurer que le build est bien effectué par ce biais. Une fois que nous aurons rôdé le processus, dans quelques mois par exemple, je pense que nous modifierons effectivement la configuration pour rendre le serveur d’intégration moins bavard…

Voici le bloc qui permet de dire au serveur d’intégration d’envoyer les mails dans tous les cas. À mettre dans le pom.xml de votre projet :

<ciManagement>
    <system>continuum</system>
    <url>http://mvnrepo.mipih.fr:8080/continuum</url>
    <notifiers>
        <notifier>
            <type>mail</type>
            <sendOnError>true</sendOnError>
            <sendOnFailure>true</sendOnFailure>
            <sendOnSuccess>true</sendOnSuccess>
            <sendOnWarning>true</sendOnWarning>
            <configuration>
                <address>notre-adresse@mipih.fr</address>
            </configuration>
        </notifier>
    </notifiers>
</ciManagement>

Dans tous les cas, j’ai dit !

Mais en fait, même comme ça, continuum ne vous enverra pas toujours la notification. En fait, il ne l’enverra que si l’état de la construction de votre projet a changé depuis la dernière fois. De base, donc, continuum n’enverra pas de mail si dexu builds successifs ont réussi.

J’ai donc cherché à savoir comment configurer continuum pour envoyer le mail inconditionnellement à la fin de chaque build. Comme je n’ai pas trouvé cette information dans la documentation de continuum, j’ai posé la question sur la liste de diffusion. J’ai eu la réponse d’Emmanuel Venisse, le projet lead de continuum :

You can configure “alwaysSend to true in WEB-INF/classes/META-INF/plexus/application.xml in the mail notifier component descriptor.

By default, we don’t send notifications if the state doesn’t change to not spam users.

Emmanuel

Dans continuum 1.0.3, c’est là : $CONTINUUM_HOME/apps/continuum/conf/application.xml. Et effectivement, après modification du bloc <alwaysSend/> à true du composant mail notifier comme suit, ça marche !

<!--
    The mail notifier
-->
<component>
    <role>org.codehaus.plexus.notification.notifier.Notifier</role>
    <role-hint>mail</role-hint>
    <implementation>
        org.apache.maven.continuum.notification.mail.MailContinuumNotifier
    </implementation>
    <requirements>
        <requirement>
            <role>org.codehaus.plexus.velocity.VelocityComponent</role>
        </requirement>
        <requirement>
            <role>org.apache.maven.continuum.store.ContinuumStore</role>
        </requirement>
        <requirement>
            <role>org.codehaus.plexus.mailsender.MailSender</role>
        </requirement>
        <requirement>
            <role>org.apache.maven.continuum.configuration.ConfigurationService</role>
        </requirement>
    </requirements>
    <configuration>
        <from-mailbox></from-mailbox>
        <from-name></from-name>
        <timestamp-format>EEE, d MMM yyyy HH:mm:ss Z</timestamp-format>
        <includeBuildResult>true</includeBuildResult>
        <alwaysSend>true</alwaysSend>
    </configuration>
</component>

En espérant que ça en aide certains…

Quelles méthodes je peux mettre dans mes « objets du domaine » ?

Gavin King, le créateur du projet Hibernate, dont le hobby est maintenant devenu Seam, a récemment publié un billet intéressant sur ce sujet.

Souvent, la question se pose : quelles méthodes doit-on modéliser dans un objet métier ? Concrètement, où dois-je mettre mon code métier ? Par exemple, est-ce que la méthode de sauvegarde d’une facture doit se trouver dans l’objet Facture lui-même ? Si je veux récupérer le nombre de clients d’une facture, dois-je mettre la méthode dans la Facture, etc. ?

Gavin a formulé d’une façon très concise une règle à laquelle je souscris totalement :

the domain model (entity classes) are the most reusable classes in my codebase

[…]

In particular, I would never write code that calls out to external services, or accesses the database, or calls an EJB/Seam/Spring component in my entity class. I want my domain model to be completely self-contained!

So anytime you find yourself wishing that entities supported injection, or find yourself writing a JNDI lookup in a method of an entity, please consider that your domain model is no longer self-contained, and will be less reusable in different execution environments.

Rien de plus à ajouter.

Problème Gmail avec Adblock plus

Depuis quelques jours, j’avais des problèmes à l’utilisation de gmail. Je n’ai pas fait le rapprochement tout de suite. La page principale de la boite de réception s’affichait, mais cliquer sur un message n’affichait jamais ce dernier. Certaines fois, même, Firefox m’affichait le message indiquant qu’un “script (javascript) ne répond pas”…

Après réflexion, je me suis demandé si adblock plus, l’extension anti-pub pour firefox que j’ai installée ne pouvait pas être en cause ? Bingo avec Google. Je n’ai par contre pas compris pourquoi les billets comme celui-ci dataient déjà de 2005, alors que je suis persuadé que ça fait une ou deux semaines au moins que j’utilisais déjà conjointement adblock plus et gmail sans soucis. Peut-être une mise à jour d’adblock plus récente que j’aurais faite sans y faire attention ?

Bref, la solution est simple. Il suffit d’ajouter mail.google.com à la liste blanche. Pour faire ceci, on peut se référer au billet en lien ci-dessus ou à la documentation d’adblock plus. En fait, pour ajouter un filtre à la liste blanche, il faut simplement préfixer le filtre par @@ (enfin, simplement, faut le savoir, quand même…).

Une fois ceci fait, tout roule normalement à nouveau.

44 balises en 5 minutes...

Via Prendre un café, un petit test rigolo sur vos connaissances HTML4 :

44

Pas trop mal. J’ai honte d’avoir oublié de citer acronym, abbr que j’ai déjà pas mal utilisé, et toutes les balises des formulaires ;-).

Grève à Toulouse : toujours aucun problème

N’hésitez pas à prendre le métro, il fonctionne parfaitement. Les bus étaient, paraît-il, moins nombreux le premier jour, mais pratiquement à 100% aujourd’hui…

Allez, encore un peu de patience, la réforme va finir par passer :-).

Limitation Oracle antédiluvienne

Je découvre avec une relative stupeur que la taille maximale des noms de tables, de colonnes, de contraintes est limitée sur Oracle à 30 caractères seulement !

Imaginez que vous ayez une contrainte d’intégrité référentielle entre deux tables :

• PRODUIT
• CATEGORIE_PRODUIT

Par convention, on préfixe souvent ces contraintes de clés étrangères par FK (voire C_FK par exemple, pour Constraint et Foreign Key). Ça me donne quelque chose comme ça :

• FK_PRODUIT_CATEGORIE_PRODUIT

Là, j’ai 28 caractères, je passe limite. Si je rajoute “C_”, je suis à fond…

Imaginons maintenant que votre fonctionnel vous indique qu’il y a une relation de réflexivité sur CategorieProduit. Les catégories de produit forment en effet un arbre avec des catégories, des sous-catégories, etc. Ben là, vous oubliez le nommage ci-dessus :

• FK_CATEGORIE_PRODUIT_PRODUIT_CATEGORIE_PRODUIT, ça passe pas…

Autre cas, si vous avez deux relations entre deux mêmes tables. Par exemple, Adresse et Client : un client peut avoir une adresse de facturation et une adresse de livraison. En base, on doit donc retrouver deux contraintes d’intégrité. La première idée qui vient est de concaténer par exemple le rôle au nommage ci-dessus. Euuu, ça commence à exclure pas mal de cas.

Franchement, à l’occasion du passage de la mise à jour de Oracle v10, Oracle aurait pu supprimer ou au moins augmenter cette limitation antédiluvienne !!! Pour la petite histoire, cette limitation n’existe pas sur les autres SGBD que nous pouvons utiliser : HSQLDB, MySQL, PostgreSQL… Je comprends mieux pourquoi les schémas d’entreprise sont truffés de noms absolument incompréhensibles. L’auto-documentation du nommage est impossible avec une limitation aussi importante.

À l’heure de l’auto-complétion omniprésente, il est courant d’avoir des variables qui atteignent 30 caractères. Je ne dis pas qu’il faut forcément des noms de variable à rallonge, mais si la longueur apporte en clarté, en maintenabilité, en compréhension, ne vous en privez surtout pas !

Très très déçu par Oracle sur ce coup là.

Grève : pas de problème demain ?

Sur le site de Tisséo, la RATP toulousaine, dirons-nous pour nos amis parisiens :

Le 18 octobre

[…]

Le trafic du métro ne devrait pas être affecté.

J’essaierai donc de prendre le métro demain, sinon ce sera vélo ou moto. Bon, en même temps, je n’ai que 6,5km de chez moi au boulot… Aaaah Paris, je suis content de ne plus y être :-).

Citation du jour

De A.B., Software IT Architect chez IBM, reçu chez nous aujourd’hui : “Les multiples acronymes à deux ou trois lettres, c’est vachement bien pour les commerciaux. Personne ne comprend rien et tout le monde est d’accord ! Mais en dév, c’est chiant !”.

La blague du jour

Seb, à un collègue :

Toi, t’es un HighGlandeur !

Une citation immortelle. Très bon ! :-) .

UPDATE : En train d’écrire ce billet, un collègue nouvellement arrivé regarde mon écran et me demande : “Tiens !? batmat.net, tu connais ?”. Moi : “Ben, euuu, comment ça ? Tu rigoles ? (comprenant et rougissant) oui, euu, c’est mon blog…” Et là, comme dit Seb, érection molle :-D .

Excuses reçues

Je les publierai bientôt en supprimant le nom de l’entreprise, mais j’ai reçu un courrier d’excuses à propos de l’affaire que j’ai expliquée l’année dernière en février (le billet du 8 février 2007).

Comme je suis en vacances et je paye cher mes accès au net, je verrai plus tard pour trouver une solution plus propre (notamment pour les permaliens vers le billet en question). J’ai en effet pour le moment simplement mis le billet offline.

Sur ce, je retourne à la plage (bon, en fait, je déconne, il pleut là :-)).