Le coeur d'un projet Maven 2 est le mod�le objet projet (appel� POM pour project object model). Il contient une description d�taill�e de votre projet, avec en particulier des informations concernant le versionnage et la gestion des configurations, les d�pendances, les ressources de l'application, les tests, les membres de l'�quipe, la structure et bien plus encore. Le POM prend la forme d'un fichier XML (pom.xml) qui est plac� dans le r�pertoire de base de votre projet. Un fichier pom.xml est pr�sent� ci-dessous :

<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.javaworld.hotels</groupId>
   <artifactId>HotelDatabase</artifactId>
   <packaging>war</packaging>
   <version>1.0-SNAPSHOT</version>
   <name>Base de donn�es des hotels</name>
   <url>http://www.hoteldatabase.com</url>
   <dependencies>
      <dependency>
         <groupId>junit</groupId>
         <artifactId>junit</artifactId>
         <version>3.8.1</version>
         <scope>test</scope>
      </dependency>
   </dependencies>
</project>

Les cycles de vie des projets sont un concept central de Maven 2. La plupart des d�veloppeurs sont familiers avec les notions de phases du build comme compile, test et deploy. Ant a des cibles (targets) avec des noms semblables. Dans Maven 1, les plug-ins correspondant sont appel�s directement. Pour compiler le code source java, par exemple, le plug-in java est utilis� :

$maven java:compile

Dans Maven 2, cette notion est standardis�e dans un groupe de phases de cycle de vie bien d�finies et d�termin�es (voir figure 2). Au lieu de lancer des plug-ins, dans Maven 2, le d�veloppeur lance l'action li�e � une phase du cycle de vie :

$mvn compile

Voil� quelques-unes unes des phases les plus utiles du cycle de vie Maven 2 :

• generate-sources: G�n�re le code source suppl�mentaire n�cessit� par l'application, ce qui est g�n�ralement accompli par les plug-ins appropri�s.
• compile: Compile le code source du projet
• test-compile: Compile les tests unitaires du projet
• test: Ex�cute les tests unitaires (typiquement avec Junit) dans le r�pertoire src/test
• package: Mets en forme le code compil� dans son format de diffusion (JAR, WAR, etc.)
• integration-test: R�alise et d�ploie le package si n�cessaire dans un environnement dans lequel les tests d'int�gration peuvent �tre effectu�s.
• install: Installe les produits dans l'entrep�t local, pour �tre utilis� comme d�pendance des autres projets sur votre machine locale.
• deploy: R�alis� dans un environnement d'int�gration ou de production, copie le produit final dans un entrep�t distant pour �tre partag� avec d'autres d�veloppeurs ou projets.

Beaucoup d'autres phases du cycle de vie sont disponibles. Voir les r�f�rences pour plus de d�tails.

Ces phases illustrent le b�n�fice des pratiques recommand�es, encourag�es par Maven 2 : une fois que le d�veloppeur est familier avec les phases principales, il devrait se sentir � l'aise avec les phases du cycle de vie de n'importe quel projet Maven.

Les phases du cycle de vie invoquent les plug-ins n�cessaires pour faire le travail. Appeler une phase du cycle de vie appelle automatiquement les phases pr�c�dentes du cycle de vie. Comme les phases du cycle de vie sont en nombre limit�, faciles � comprendre et bien organis�es, se familiariser avec le cycle de vie d'un nouveau projet Maven 2 est tr�s simple.

Une des nouveaut�s de Maven 2 est la gestion des d�pendances transitives. Si vous avez d�j� utilis� un outil comme urpmi sur une Linux box, vous devez savoir ce que d�pendance transitive veut dire. Avec Maven 1, vous aviez � d�clarer chacun des JAR dont avait besoin, directement ou indirectement, votre application. Par exemple, pouvez vous lister les JARs n�cessaires � une application Hibernate ? Avec Maven 2, vous n'avez pas besoin. Vous dites juste � Maven les biblioth�ques dont vous avez besoin, et Maven se charge des biblioth�ques dont vos biblioth�ques ont besoin (et ainsi de suite).

Supposons que vous voulez utiliser Hibernate dans votre projet. Vous auriez simplement � ajouter une nouvelle d�pendance � la section dependencies de votre pom.xml, comme suit :

   <dependency>
      <groupId>hibernate</groupId>
      <artifactId>hibernate</artifactId>
      <version>3.0.3</version>
      <scope>compile</scope>
   </dependency>

C'est tout! Vous n'avez pas besoin de courir apr�s les autres JARs (et dans quelle version) dont a besoin Hibernate 3.0.3 pour fonctionner : Maven le fait pour vous !

La structure XML des d�pendances dans Maven 2 est proche de celle utilis�e dans Maven 1. La diff�rence principale est l'attribut scope qui est expliqu� dans la section suivante.

Dans une application d'entreprise du monde r�el, vous n'avez pas n�cessairement besoin d'inclure toutes les d�pendances dans l'application d�ploy�e. Certains des JARs sont n�cessaires uniquement pour les tests unitaires, alors que d'autres seront fournis � l'ex�cution par le serveur d'application. En utilisant la technique de la port�e de d�pendances, Maven 2 vous permet d'utiliser certain JAR uniquement quand vous en avez besoin et de les exclure du classpath quand vous n'en avez pas besoin.

Maven mets � disposition quatre port�s de d�pendances :

• compile: Une d�pendance de port�e compile est disponible dans toutes les phases. C'est la valeur par d�faut.
• provided: Une d�pendance de port�e provided est utilis�e pour compiler l'application, mais ne sera pas d�ploy�e. Vous utiliserez cette port�e quand vous attendez du JDK ou du serveur d'application qu'il vous mette le JAR � disposition. L'API servlet est un bon exemple.
• runtime: Les d�pendances de port�es runtime ne sont pas n�cessaires pour la compilation, uniquement pour l'ex�cution, comme les drivers JDBC (Java Database Connectivity).
• test: Les d�pendances de port�es test sont uniquement n�cessaires pour compiler et ex�cuter les tests (par exemple Junit).

Une partie importante de tout projet est la communication interne. Sans �tre une solution parfaite, un site web technique et centralis� permet de grandes avanc�es dans la vision commune d'une �quipe. Avec un effort minimal, vous pouvez mettre en place un site web de qualit� professionnelle en tr�s peu de temps.

Cela prend encore une autre dimension quand la g�n�ration du site Maven est int�gr�e dans le processus de build en utilisant l'int�gration continue ou les builds nocturnes automatis�s. Un site Maven peut publier, sur une base quotidienne :

• Des informations g�n�rales sur le projet, comme les entrep�ts de source, le suivi des anomalies, les membres de l'�quipe, etc.
• Les tests unitaires et les rapports de couverture des tests unitaires
• Des revues de code automatis�es avec Checkstyle ou PMD
• Des informations sur la configuration ou le versionnage
• Les d�pendances
• La JavaDoc
• Le code source index� et r�f�ren�able, sous un format HTML
• La liste des membres de l'�quipe
• Et beaucoup plus encore

Encore une fois, n'importe quel d�veloppeur cal� sur Maven saura imm�diatement ou regarder pour se familiariser avec un projet Maven 2.

Maintenant que nous avons vu quelques-unes unes des notions de base utilis�es dans Maven 2, regardons comment cela se passe dans le monde r�el. La fin de cet article examine comment nous pourrions utiliser Maven 2 pour un projet J2EE simple. L'application de demo mod�lise un syst�me de base de donn�es d'h�tels (simplifi�). Pour illustrer comment Maven 2 traite les d�pendances entre projets et composants, cette application sera construite autour de deux composants (voir figure 3) :

• Un composant m�tier : HotelDatabase.jar
• Un composant application web: HotelWebApp.war

Vous pouvez t�l�charger le code source pour suivre cet exemple dans les ressources.

Nous commen�ons par configurer votre environnement de travail. Dans les projets r�els, vous aurez souvent � d�finir et � configurer un environnement ou des param�tres sp�cifiques � un utilisateur, qui ne devront pas �tre communiqu�s � tous les utilisateurs. Si vous �tes derri�re un proxy par exemple, vous aurez besoin de mettre en place la configuration de votre proxy, afin que Maven puisse t�l�charger des JARs issus d'entrep�ts sur le web. Pour les utilisateurs de Maven 1, les fichiers build.properties et project.properties remplissaient ce travail. Avec Maven 2, ils ont �t� remplac�s par un fichier settings.xml qui va dans le r�pertoire $HOME/.m2 (ndt : maintenant $MVN_HOME/conf). Voici un exemple :

<?xml version="1.0" encoding="UTF-8"?>
<settings>
  <proxies>
    <proxy>
      <active/>
      <protocol>http</protocol>
      <username>dupont</username>
      <password>lupin</password>
      <port>8080</port>
      <host>my.proxy.url</host>
      <id/>
    </proxy>
  </proxies>
</settings>

L'�tape suivante est de cr�er un nouveau squelette de projet Maven 2 pour le composant m�tier. Maven 2 propose le plug-in archetype, qui construit une structure de projet Maven 2. Ce plug-in est tr�s utile pour mettre rapidement en place l'environnement d'un projet basique. Par d�faut, archetype produit un mod�le de projet pour une biblioth�que JAR. Plusieurs autres types d'artefact sont disponibles, pour d'autre type de projets, comme les applications web, les plug-ins Maven et bien d'autres.

Executez la commande suivante pour mettre en place votre projet HotelDatabase.jar :

mvn archetype:create -DgroupId=com.javaworld.hotels
	-DartifactId=HotelDatabase -Dpackagename=com.javaworld.hotels

Vous avez maintenant une structure de projet Maven 2 toute neuve. Allez dans le r�pertoire HotelDatabase pour continuer ce tutoriel.

Nous allons maintenant impl�menter la logique m�tier. La classe Hotel est un simple JavaBean. La classe HotelModel impl�mente deux services: la m�thode trouveVillesDiponibles(), qui liste toutes les villes disponibles et la m�thode trouveHotelsParVille() qui liste les h�tels dans une ville donn�e. Une impl�mentation basique de la classe HotelModel est pr�sent�e ici :

package com.javaworld.hotels.model;

import java.util.ArrayList;
import java.util.List;

import com.javaworld.hotels.businessobjects.Hotel;

public class HotelModel {

    /**
     * La liste de toutes les villes connues dans la base de donn�es.
     */
    private static String[] villes = { "Paris", "Londres" };

    /**
     * La liste de tous les hotels de la base de donn�es.
     */
    private static Hotel[] hotels = {
            new Hotel("Hotel Latin", "Quartier latin", "Paris", 3),
            new Hotel("Hotel Etoile", "Place de l'Etoile", "Paris", 4),
            new Hotel("Hotel Vendome", "Place Vendome", "Paris", 5),
            new Hotel("Hotel Hilton", "Trafalgar Square", "Londres", 4),
            new Hotel("Hotel Ibis", "The City", "Londres", 3), };

    /**
     * Retourne les h�tels dans une ville donn�e.
     * @param ville le nom de la ville
     * @return une liste d'objets Hotel
     */
    public List <Hotel> trouveHotelsParVille(String ville) {
        List <Hotel> hotelsTrouves = new ArrayList <Hotel>();
        for (Hotel hotel : hotels) {
            if (hotel.getVille().equalsIgnoreCase(ville)) {
                hotelsTrouves.add(hotel);
            }
        }
        return hotelsTrouves;
    }

    /**
     * Retourne la liste des villes de la base de donn�es qui ont un h�tel.
     * @return une liste des noms de villes
     */
    public String[] trouveVillesDiponibles() {
        return villes;
    }
}

Maintenant, passons aux tests de l'application. Quelques classes de test simples peuvent �tre trouv�es dans le code source. Les tests unitaires sont (ou devraient �tre !) une partie importante de toute application Java. Maven int�gre compl�tement les tests unitaires dans le cycle de d�veloppement. Pour ex�cuter tous vos tests unitaires, vous appelez la phase test du cycle de vie :

mvn test

Une possibilit� int�ressante de Maven 2 est son utilisation des expressions r�guli�res et du param�tre test pour contr�ler les tests que vous voulez ex�cuter. Si vous voulez uniquement ex�cuter un test, vous pouvez utiliser le param�tre test :

mvn test -Dtest=HotelModelTest

Si vous voulez ex�cuter un sous-ensemble de vos tests unitaires, vous pouvez utiliser une expression r�guli�re. Par exemple pour ex�cuter toutes les classes finissant par ModelTest :

mvn test -Dtest=*ModelTest

Une fois que vous �tes satisfait de vos tests, vous pouvez construire et d�ployer votre nouveau JAR. La commande install compile, test et mets en paquet vos classes dans un fichier jar puis le deploy dans votre entrep�t Maven 2 local, d'o� il peut �tre utilis� par d'autres projets.

mvn install

Maintenant nous voulons utiliser cette biblioth�que pour une application web. Pour simplifier, notre application web consistera uniquement en une JSP (JavaServer Page) qui utilisera directement la classe HotelModel. Tout d'abord nous cr�ons un nouveau projet d'application web en utilisant le plug-in archetype :

mvn archetype:create -DgroupId=com.javaworld.hotels -DartifactId=HotelWebapp
	-Dpackagename=com.javaworld.hotels -DarchetypeArtifactId=maven-archetype-webapp

Ensuite, nous avons besoin d'inclure notre JAR m�tier dans cette application. Tout ce que nous avons � faire est de rajouter une d�pendance au nouveau pom.xml pointant sur le composant HotelDatabase :

    <dependency>
      <groupId>com.javaworld.hotels</groupId>
      <artifactId>HotelDatabase</artifactId>
      <version>1.0-SNAPSHOT</version>
    </dependency>

Maintenant, nous impl�mentons la JSP unique: Elle liste simplement les villes disponibles et, si une ville est choisie, liste les h�tels correspondants :

<html>
<body>
<h2>Application Tutoriel pour la base de donn�es des hotels</h2>
<%@ page import="
   java.util.List,
    com.javaworld.hotels.businessobjects.Hotel,
    com.javaworld.hotels.model.HotelModel"
%>
<%
   HotelModel model = new HotelModel();
   String[] villes = model.trouveVillesDiponibles();
   String villeSelectionnee = request.getParameter("ville");
   List<Hotel> hotelList = model.trouveHotelsParVille(villeSelectionnee );
%>
   <h3>Choisissez une destination</h3>
   <form action="index.jsp" method="get">
     Merci de choisir une ville :
      <SELECT name="ville">
         <OPTION value="">---Toutes les villes ---</OPTION>
         <%
         for(String villeNom : villes ){
         %>
          <OPTION value="<%=villeNom %>"><%=villeNom %></OPTION>
         <%
         }
         %>
      </SELECT>
      <BUTTON type="submit">Chercher</BUTTON>
   </form>
   <% if (hotelList.size() > 0) { %>
      <h3>H�tels disponibles � <%=villeSelectionnee %> </h3>
      <table border="1">
           <tr>
             <th>Nom</th>
             <th>Adresse</th>
             <th>Ville</th>
             <th>Cat�gorie</th>
            </tr>
         <%
         for(Hotel hotel : hotelList){
         %>
           <tr>
             <td><%=hotel.getNom()%></td>
             <td><%=hotel.getAdresse()%></td>
             <td><%=hotel.getVille()%></td>
             <td><%=hotel.getEtoiles()%> �toiles</td>
            </tr>
         <%
         }
         %>
       </table>
    <%}%>
</body>
</html>

Nous ex�cutons maintenant mvn install depuis le r�pertoire HotelWebapp ; cela va compiler, empaqueter et d�ployer le fichier HotelWebapp.war dans notre entrep�t local (vous pouvez �galement le trouver dans le r�pertoire target si n�cessaire). Maintenant vous pouvez d�ployer ce fichier war dans votre serveur d'application favori et voir ce que vous avez (voir figure 4).

Maven 2 arrive avec un nombre toujours croissant de plug-ins qui ajoute des fonctionnalit�s suppl�mentaires � votre processus de build sans grand effort. Pour utiliser un plug-in, vous le liez � une phase du cycle de vie. Maven trouvera alors quand (et comment) l'utiliser. Certains plugs-in sont d�j� utilis�s par Maven par derri�re, vous avez donc uniquement besoin de les d�clarer dans la section plugins de votre fichier pom.xml. Le plug-in suivant, par exemple, est utilis� pour compiler du code avec le J2SE 1.5 :

  ...
   <build>
      ...
      <plugins>
         <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-compiler-plugin</artifactId>
            <configuration>
               <source>1.5</source>
               <target>1.5</target>
            </configuration>
         </plugin>
      </plugins>
   </build>

Dans d'autres cas, vous liez le plug-in � une phase du cycle de vie de fa�on � ce que Maven sache quand l'utiliser. Dans l'exemple suivant, nous ex�cutons une tache Ant standard. Pour ce faire, nous lions le plug-in maven-antrun-plugin � la phase generate-sources et ajoutons la tache Ant entre les balises tag, comme montr� ici :

  ...
<build>
      ...
    <plugins>
       <plugin>
          <artifactId>maven-antrun-plugin</artifactId>
          <executions>
            <execution>
              <phase>generate-sources</phase>
              <configuration>
                <tasks>
                  <!-- Les taches ant vont ici -->
                </tasks>
              </configuration>
              <goals>
                <goal>run</goal>
              </goals>
            </execution>
          </executions>
        </plugin>
     </plugins>
  </build>

Maven 2.0 est un outil tr�s puissant qui simplifie et standardise �norm�ment le processus de build. En favorisant une organisation standard des projets et des bonnes pratiques reconnus, Maven �te une bonne quantit� de travail. Et des plugs-in standards, comme le g�n�rateur de site web, offrent des outils collaboratifs int�ressants avec peu d'effort. V�rifiez par vous-m�me !