Transférer une application d'Apache Ant au Mavan

Transformer Apache Ant en Maven

Ce site ne sera plus alimenté de contenu après août 2014. Tous les nouveaux articles seront redigés pour www.waitingforcode.com

Maintenant, quand on connaît les bases de Maven, on peut s'occuper d'organiser notre projet selon l'architecture standard du Maven.

Différences dans la structure

Apache Ant, sans son extension Ivy, ne permet pas gérer les dépendances par un fichier de configuration. On est obligés de télécharger les packages et de les placer dans le classpath (/lib dans notre structure). C'est là ou Ant va aller chercher les packages lors de la compilation. Sous Maven on n'a plus besoin de stocker les fichiers physiquement (sauf certaines exceptions) dans un répertoire. Il suffit juste de les configurer dans le fichier qui "pilote" l'application.

Le transfert d'une application sur Maven nécessite également la réorganisation des tests unitaires. Jusque là on les traitait comme une entité intégrale de l'application. Ils étaient placés ensemble, avec d'autres éléments du package (annotations, modèle, contrôleurs...). Sous Maven, les tests font partie d'une entité indépendante qui peut posséder ses propres resources (fichiers de configuration).

Transférer une application d'Apache Ant sur Maven

La procédure du transfert va commencer par la création du projet vide d'une application web. Maven permet de le faire avec la commande mvn archetype:generate. On remarque vite que la notion de projet a disparu au profit d'un archetype. Voici la commande complète mvn archetype:generate -DgroupId=com.example.library -DartifactId=LibrarySpringSample -DarchetypeArtifactId=maven-archetype-webapp -DinteractiveMode=false.

Le lancement de cette commande créera un répertoire dont le nom correspond au paramètre -DartifactId. Ensuite, Maven y placera la structure de base pour les projets des applications web. La structure en question se présente ainsi :

   |-src
   |---main
   |-----resources
   |-----webapp
   |-------index.jsp
   |-------WEB-INF
   |---------web.xml
   |-pom.xml

Le répertoire src regroupe toutes les resources (Java et fichiers de configuration) du projet et il devrait être sous un système de contrôle de version. Son contenu, placé dans le répertoire main, contient les resources (fichiers de configuration, modèles d'Apache Tiles etc.) et les données spécifiques à l'application web (webapp).

Mais alors où placer les classes Java de notre projet et les tests ? En ce qui concerne les premières, elles doivent se trouver dans le répertoire /src/main/java. L'arborescence du répertoire doit correspondre à l'URL de notre projet dans le sense inverse. Dans notre cas, la webapp sera disponible sous l'adresse library.example.com. Le chemin vers les classes sera dont le suivant /src/main/java/com/example/library.

Pour les tests, ils doivent se trouver dans /src/test. Les classes doivent ensuite reprendre le même chemin que dans le cas précédent (/src/test/java/com/example/library) tandis que les resources (fichier de création de l'ApplicationContext) doivent être rajoutées à la racine des tests (/src/test/resources).

Ensuite, il faut supprimer le fichier /src/main/webapp/WEB-INF/index.jsp . Sinon, il va apparaître au moment du lancement de notre application. Voici donc la structure qu'on va avoir après avoir effectué ces changements :

   |-src
   |---main
   |-----java
   |-------com
   |---------example
   |-----------library
   |-----resources
   |-----webapp
   |-------WEB-INF
   |---------web.xml
   |---test
   |-----java
   |-------com
   |---------example
   |-----------library
   |-----resources
   |-pom.xml

Construire un pom.xml

Comme on l'a déjà évoqué, le fichier qui pilote le projet s'appelle pom.xml et est placé à la racine de l'application. Tout d'abord, on présentera le descriptif du projet, expliqué dans l'article de l'introduction au Maven :

<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">
  <modelVersion>4.0.0</modelVersion>
  <groupId>com.example.library</groupId>
  <artifactId>LibrarySpringSample</artifactId>
  <packaging>war</packaging>
  <version>1.0-SNAPSHOT</version>
  <name>LibrarySpringSample Maven Webapp</name>
  <url>http://maven.apache.org</url>
</project>

Rien d'extraordinaire à ce niveau-là, juste les informations sur le projet. En ce qui concerne la partie qui gère les dépendances, elle n'est pas mysterieuse non plus. Son rôle principale consiste à lister les dépendances ainsi que les versions qui nous intéressent. Voici comment se présente la gestion de dépendance standarde :

  <!-- ... -->
  <dependencies> 
    <!-- Spring dependencies -->
    <dependency>
      <groupId>org.springframework</groupId>
      <artifactId>spring-context</artifactId>
      <version>3.1.3.RELEASE</version>
    </dependency>
  </dependencies>

Rien de très compliqué. Les choses plus complexes commencent avec des JARs qui sont fournis (balise scope avec la valeur provided). En fait, certains packages doivent être téléchargés et installés manuellement dans le répositoire local du Maven. On l'expliquera plus tard. Ces fichiers-là sont définis dans notre pom.xml de la manière suivante :

    <dependency>
      <groupId>javax</groupId>
      <artifactId>javaee-api</artifactId>
      <version>16</version>
      <scope>provided</scope>
    </dependency>

Maintenant il suffit de préciser le nom du projet :

  <build>
    <finalName>LibrarySpringSample</finalName>
  </build>

Et lancer la création du package avec la commande mvn clean; mvn package.

Dans cet article on a rapidement vu comment adapter la structure d'une application "personnalisée" à la structure standard du Maven. Cela facilite incontestablement la compréhension du projet à des personnes extérieures. Aussi la gestion des dépendances facilite la maintenance et l'évolution du projet.

Bartosz KONIECZNY Maven

Une question ? Une remarque ?

*

*

Moi

Développeur d'applications Internet et journaliste passionné par l'adjectif français. Un aigle polonais orienté vers la progression, volant très haut et écoutant du zouk après les matches du foot français.

Vous appréciez mon travail ?

Pour contribuer au développement de ce site, ou pour remercier pour des articles rédigés, vous pouvez faire un don.

Un conseil PHP

Comment créer un signature key pour OAuth

Un signature key est l'un des deux composants qui constituent la signature de la requête OAuth. Il est composé de : - la clé secrète que le fournisseur (Google, Yahoo...) attribue au client, elle doit être toujours présente dans le signature key - le ticket secret qui est renvoyé à de différentes étapes de l'échange avec le web service du fournisseur; s'il est absent (comme lors de la récupération du ticket de la requête), il faut alors passer une chaîne de caractères vide Les deux paramètres doivent être encodés. Une méthode pour générer le signature key peut se présenter ainsi :

function setSignatureKey($tokenSecret)
{
  return str_replace('%7E', '~', rawurlencode($this->userData['secret'])).'&'.str_replace('%7E', '~', rawurlencode($tokenSecret));
}