Blogounage

Aller au contenu | Aller au menu | Aller à la recherche

vendredi 9 octobre 2009

[Hudson] How to set a private maven repository by job and easily be able to delete them

When building maven projects with hudson, there's some common best practices about maven repositories handling :

  1. isolate maven repositories between jobs
  2. regularly purge repositories

The problem

The basic way to do it is to activate the hudson per-job option : "Use private Maven repository". But the thing is you have to do it for EVERY new job you add. There is no way inside hudson to activate it globally.

Documented solution

If you look at hudson help for this option, you'll see a link to a simple solution that specify the repository directly in the maven settings.xml file. The tip is to redefine the localRepository tag inside settings with this special value :

<localRepository>${env.WORKSPACE}/m2_repo</localRepository>

This way, you're done with the first best practice : isolate maven repositories. But not yet with the regularly purge repositories one. Actually, using this option will put the m2_repo inside each hudson job workspace. So, finding and deleting them could become a bit cumbersome. You'd have to cron something like find . -name m2_repo -exec rm -rf "{}" \;.

Even better

As you might have understood, I was not thoroughly satisfied with this solution. I wanted to be able to really easily delete the repositories. So I just changed the option above to have them all inside the same root directory under ~/.m2/repositories, one per job.

Quite simple in fact, instead, just use :

<localRepository>/some/path/.m2/repositories/${env.JOB_NAME}/repository</localRepository>

This way, the only thing you have to put in the cron job is rm -rf /some/path/.m2/repositories/. A bit more straightforward, isn't it? :-)

Hope this helps.

mardi 24 juin 2008

Quelques déclarations XSD ou DTD de formats XML connus

C'est le genre de chose qu'il est sympathique d'avoir écrit en tête de ce type de fichier pour disposer de l'auto-complétion XML dans son IDE favori. Lorsque j'utilise un nouveau format XML, la première chose que je cherche est en effet à ajouter cet entête pour me faciliter la vie (et aux autres une fois commité :)).

Note : dans la liste ci-dessous, je ne mets pas le prologue XML pour gagner en concision. Toutefois, ça ne fait jamais de mal de le mettre. Personnellement j'essaie de le mettre systématiquement.

Hibernate : mappings hbm.xml

Même s'il vaut mieux à mon avis passer aux annotations lorsqu'on en a la possibilité, voici une déclaration de DTD qui fonctionne chez moi pour ceux qui ont encore des mappings hibernate à la sauce XML :

<!DOCTYPE hibernate-mapping PUBLIC "-//Hibernate/Hibernate Mapping DTD 3.0//EN" 
"http://hibernate.sourceforge.net/hibernate-mapping-3.0.dtd">

<hibernate-mapping package="net.batmat.domaine">
...
</hibernate-mapping>

Java Persistence : persistence.xml

Pour ceux qui utilisent Java Persistence, cette "sous-spécification" des EJB3 devenue une spécification autonome dans sa version 2 :

<persistence xmlns="http://java.sun.com/xml/ns/persistence"
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xsi:schemaLocation="
                http://java.sun.com/xml/ns/persistence
                http://java.sun.com/xml/ns/persistence/persistence_1_0.xsd"

        version="1.0">

...
</persistence>

Spring : fichier de contexte XML

Depuis la version 2, ils ont subdivisé leur format XML en différents namespaces. Voici un exemple fonctionnel qui met en œuvre un certain nombre de ces espaces de nommages XML. Je laisse en exercice le passage à Spring 2.5 (que nous utilisons, d'ailleurs, mais on n'a pas mis à jour le XML) ou l'ajout d'un autre namespace dont vous auriez besoin :-).

<beans xmlns="http://www.springframework.org/schema/beans"
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xmlns:util="http://www.springframework.org/schema/util"
        xmlns:aop="http://www.springframework.org/schema/aop"
        xmlns:tx="http://www.springframework.org/schema/tx"
        xsi:schemaLocation="
                http://www.springframework.org/schema/beans
                http://www.springframework.org/schema/beans/spring-beans-2.0.xsd
                http://www.springframework.org/schema/util
                http://www.springframework.org/schema/util/spring-util-2.0.xsd
                http://www.springframework.org/schema/tx
                http://www.springframework.org/schema/tx/spring-tx-2.0.xsd
                http://www.springframework.org/schema/aop
                http://www.springframework.org/schema/aop/spring-aop-2.0.xsd"
>

...
</beans>

Maven : pom.xml

Celui-là, il est sacrément pratique vu la taille du truc :

<project xmlns="http://maven.apache.org/POM/4.0.0"
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
                      http://maven.apache.org/maven-v4_0_0.xsd"
>

...
</project>

Voilà déjà pour cette fois. Une fois cet entête ajouté, dans Eclipse par exemple, tapez juste "<" quelque part et vous verrez la liste des balises apparaître et leur documentation si les auteurs l'ont indiquée (après qu'Eclipse ait pu récupérer le XSD sur Internet, bien sûr) : Auto-complétion du XML avec Eclipse

Si vous en avez d'autres, n'hésitez pas à les poster (ou à les demander, si je suis dans un bon jour) dans les commentaires.

Update 01/10/2008, ajout du application.xml des EAR :

<!DOCTYPE application PUBLIC "-//Sun Microsystems, Inc.//DTD J2EE Application 1.3//EN" 
     "http://java.sun.com/dtd/application_1_3.dtd">

<application id="mon appli">
...
</application>

vendredi 30 novembre 2007

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