Gestion des versions dans Maven: SNAPSHOT ou pas SNAPSHOT?

Introduction

MAVEN est un outil qui permet de gérer le cycle de vie d'un projet d'une manière portable. Parmi les fonctionnalités les plus importantes, on peut citer :

  • la structure du projet qui est normalisée et indépendante du langage et de la plateforme utilisés (Java, PHP, FLEX...);
  • l'incitation à utiliser un dépôt central abritant les librairies utilisées par nos projets et assurant le stockage des ces derniers pour une utilisation tierce (livraison à un client ou bien utilisation par un autre projet).

Un aspect important dans l'utilisation de MAVEN est la gestion des numéros de version d'un projet et de ses dépendances. En effet, avec MAVEN, j'ai découvert la notion de SNAPSHOT et l'objectif de ce billet est de partager mon retour d'expérience concernant :

  • La mise en place d'une pratique commune de versionning.
  • La mise en place d'un déploiement continu.
  • L'automatisation de la distribution d'un projet.

Sécurité et Maven : Pourquoi s’en priver ?

Nous sommes poussés de plus en plus chaque jour à sécuriser nos données et autres accès confidentiels, alors pourquoi laissons-nous encore nos informations d'accès en clair sur nos postes de développement ou environnements de pré-production et tout particulièrement les codes d'accès qui s'y rattachent? Je vous l'accorde, s'il s'agit d'un serveur "perso" de développement où est le problème, mais s'il s'agit d'un serveur central, hébergeant de plusieurs applications avec politique de sécurité et tutti quanti, là, cette question se pose. Heureusement Maven est là pour nous aider à ne plus cacher la clef sous le paillasson.

Déploiement automatisé (Tomcat et cargo-maven2-plugin)

Dans un contexte d'intégration continue il est fréquent de déployer régulièrement l'application sur un serveur d'application.
Pour automatiser ce processus on peut utiliser le plugin Maven 2 cargo-maven2-plugin pour déployer l'application sur Tomcat à l'aide de la configuration suivante:

<!-- DEPENDENCY CONFIG -->
<dependencies>
   <dependency>
     <groupId>${webapp.groupId}</groupId>
     <artifactId>${webapp.artifactId}</artifactId>
     <version>${webapp.version}</version>
     <type>${webapp.type}</type>
   </dependency>
</dependencies>

<profiles>
    <!-- WEB APP TO DEPLOY-->
    <profile>
      <id>MyApp</id>
      <properties>
        <webapp.groupId>sweetdev-ria</webapp.groupId>
        <webapp.artifactId>sweetdev-ria-gettingStarted</webapp.artifactId>
        <webapp.type>war</webapp.type>
        <webapp.version>3.5.1</webapp.version>
       </properties>
    </profile>

   <!-- REMOTE SERVER CONFIG-->
   <profile>
      <id>local</id>
      <properties>
         <tomcat.url>http://localhost:8080/manager</tomcat.url>
         <tomcat.login>tomcat</tomcat.login>
         <tomcat.password>tomcat</tomcat.password>
         <tomcat.ping>http://localhost:8080/</tomcat.ping>
      </properties>
   </profile>

   <!-- TOMCAT SERVER CONFIG-->
   <profile>
      <id>tomcat</id>
      <build>
        <plugins>
          <plugin>
             <groupId>org.codehaus.cargo</groupId>
             <artifactId>cargo-maven2-plugin</artifactId>
             <version>0.3.1</version>

             <executions>
               <execution>
                  <id>deploy-app</id>
                  <phase>install</phase>
                  <goals>
                    <goal>deployer-redeploy</goal>
                  </goals>
               </execution>
             </executions>

             <configuration>
               <container>
                 <containerId>tomcat5x</containerId>
                 <type>remote</type>
               </container>

              <configuration>
                <type>runtime</type>
                <properties>
                  <cargo.remote.username>${tomcat.login}</cargo.remote.username>
                  <cargo.remote.password>${tomcat.password}</cargo.remote.password>
                  <cargo.tomcat.manager.url>${tomcat.url}</cargo.tomcat.manager.url>
                </properties>
              </configuration>

              <deployer>
                <type>remote</type>
                <deployables>
                   <deployable>
                      <groupId>${webapp.groupId}</groupId>
                      <artifactId>${webapp.artifactId}</artifactId>
                      <type>${webapp.type}</type>
                      <pingURL>${tomcat.ping}${webapp.artifactId}-${webapp.version}</pingURL>
                      <pingTimeout>60000</pingTimeout>
                   </deployable>
                </deployables>
              </deployer>

            </configuration>
         </plugin>
      </plugins>
    </build>
  </profile>
</profiles>

Cette configuration est composée des 4 parties suivantes:

  • DEPENDENCY CONFIG : Le plugin cargo-maven2-plugin demande à ce que l'artefact déployé soit défini en temps que dépendance du projet.
  • WEB APP TO DEPLOY : Ce profil permet de définir les variables associés à l'artefact déployé.
  • REMOTE SERVER CONFIG : Ce profil permet de définir les variables associés au serveur cible.
  • TOMCAT SERVER CONFIG : Ce profil permet de définir la configuration du plugin pour déployer l'application sur Tomcat.

L'intérêt de définir plusieurs profils dans lesquels on sépare les responsabilités permet de pouvoir configurer dans un même fichier le déploiement de plusieurs applications sur plusieurs serveurs, seule la ligne de commande change.
Pour exécuter le déploiement de l'application MyApp sur Tomcat il suffit d'exécuter la commande  :

mvn install -PMyApp,local,tomcat

Dans certains cas on peut s'apercevoir que cette commande fonctionne bien la première fois mais pas la seconde!;)
Si on ouvre dans le répertoire webapp de Tomcat, on peut s'apercevoir que la structure de l'application est présente, quasi vide à l'exception d'une ou plusieurs librairies (WEB-INF/lib) et que l'on ne peut pas les supprimer manuellement.
La raison est que le serveur Tomcat garde une référence vers certaines classes ou ressources contenues dans les librairies et ne la supprime pas lorsque l'application est désinstallée.
Les références entre le serveur et les classes applicatives peuvent être induites pour plusieurs raisons : définition des paramètres de commons-logging dans la webapp, le ClassLoader applicatif qui référence de manière bidirectionnelle des librairies serveur et applicatives..etc.

La solution la plus simple pour éviter ce type de problème est de préciser à Tomcat via les paramètres antiJARLocking et antiResourceLocking du context.xml de ne pas garder de référence vers l'applicatif.
Ces paramètres du contexte applicatif peuvent être définis principalement à deux endroits:

Solution 1
Dans le context.xml applicatif qui peut être présent directement dans le WAR de l'application dans le repertoire META-INF:

<Context path="/myApp" docBase="myApp" debug="0"
reloadable="true" antiJARLocking="true" antiResourceLocking="true"/>

Solution 2
Dans le contexte globale à l'ensemble des application définit dans le fichier ${CATALINA_HOME}/conf/context.xml:

<Context  debug="0" reloadable="true" antiJARLocking="true" antiResourceLocking="true">
<!-- Default set of monitored resources -->
<WatchedResource>WEB-INF/web.xml</WatchedResource>
</Context>

Dans les deux cas les paramètres antiJARLocking et antiResourceLocking permettent de désinstaller l'application proprement via le plugin cargo-maven2-plugin.

Selenium & Maven : Mise en place

Selenium est une suite d’outils permettant d’automatiser les tests des applications web sur de multiples plateformes.
Dans ce billet, je vais présenter la mise en place de Selenium RC dans un projet géré par Maven.
Nous allons commencer par créer un projet from scratch, en gardant une architecture minimale, puis nous créerons et exécuterons notre propre test.
Dans une seconde partie, nous verrons quelques points de configuration permettant d'automatiser le lancement de nos tests.

maven – password encryption

Pour mon premier post une petite news sur maven.

Depuis la version 2.1.0 de maven il est possible de crypter les mots de passes utilisé par maven pour se connecter à un archiva d'entreprise par exemple.

Ceci peut être intéressant dans une société où archiva est lié au LDAP et permet d'éviter de mettre en clair son jolie mot de passe dans un fichier de conf.

Voici le lien de la configuration maven.

Déploiement facile avec Weblogic

De même que Goliath faisait Poids-Lourd vis-à-vis de David, Weblogic se présente de la même façon vis-à-vis de Tomcat. Ne donnerait-on pas jusqu'à son dernier lance-pierre pour pouvoir déployer aussi facilement que via le Tomcat Manager, la dernière version de notre web-app préférée sur un serveur Weblogic? Eh bien, gardez bien votre fronde dans votre poche arrière et laissez-moi vous guider sur le chemin du "easy-deploy" grâce à Maven.