Oui c’est bien ma veine d’avoir eu besoin qu’un de mes projets Seam fonctionne à la fois sous Maven et Eclipse WTP seulement maintenant, parce que tout ce que je vais décrire dans cet article ne fonctionnait pas ou très mal il y a encore quelques mois (si tant est que l’on puisse dire que ça fonctionne bien maintenant). Cet article explique comment adapter un projet JEE5 (comprenant un EAR, un EJB et un WAR) conçu sous eclipse WTP à une hiérarchie Maven manipulable aussi bien sous Eclipse qu’en ligne de commande. Le projet dans mon exemple est un projet Seam mais les informations restent valable même pour un projet JEE n’utilisant pas cette technologie. Avant d’entrer dans le vif du sujet et parce que c’est toujours productif de rappeler de quoi l’on parle, nous reviendrons sur les différents outils évoqués dans ce tutoriel et sur les avantages de faire fonctionner un projet à la fois sous WTP et Maven.
Les protagonistes
- WTP : Web Tools Platform est un ensemble de plugins Eclipse facilitant grandement le développement d’application JEE. L’aspect le plus pratique de WTP est de pouvoir compiler, packager et déployer dynamiquement sur un serveur JEE local un projet Eclipse. WTP gère aussi bien des projets JEE légers simples (WAR) que des projets complets (EAR incluant EJB et War). Le seul défaut de l’outil et que le projet n’est déployable qu’avec Eclipse. Sorti de l’IDE, il faudra avoir recours à un autre outil pour compiler, packager et déployer le projet vers un serveur.
- Maven : il s’agit d’un outil de « build » Java. Maven permet d’automatiser un certain nombre de tâches autour de la compilation, des tests, du packaging et du déploiement d’applications Java. Beaucoup décrié, Maven reste l’outil le plus populaire de sa catégorie car il facilite grandement la mise en place de software factory pour l’intégration continue. L’un des aspects de Maven les plus faciles à appréhender est la gestion des dépendances. Maven permet en effet de récupérer automatiquement les bibliothèques jar (ceci est valable pour les projets open sources, le jar d’un éditeur ne sera pas récupéré automatiquement) nécessaires à la compilation et ou l’exécution d’un projet via des fichiers de configuration (les fameux pom.xml). Par défaut Maven ne sait que compiler des sources Java, c’est la raison pour laquelle de nombreux plug-ins Maven existent permettant d’ajouter des fonctionnalités avancées au produit (dans notre cas build de projet EAR, EJB ou WAR). Maven diffère beaucoup des solutions de build historiques comme les makefile en C ou les scripts ANT sous Java, car il repose sur des conventions et n’est alimenté que par des fichiers de configuration là où les autres solutions disposent d’un langage de scripting. C’est certainement cette différence qui rend Maven aussi compliqué à maîtriser : la rencontre entre une hiérarchie de dossiers et de fichiers dont l’agencement est une convention, des fichiers de configurations permettant au moteur de travailler sur cette convention et la « boîte noire » que constituent le moteur de Maven ainsi et ses plugins.
- M2eclipse : est un plug-in Eclipse développé par la société Sonatype, permettant d’intégrer Maven à Eclipse. Pour faire court m2eclipse permet de construire des projets avec Maven sous Eclipse tout en gardant certains automatismes de l’IDE. Avec m2eclipse on bénéficie du meilleur des deux mondes. Cependant m2eclipse ne supportait qu’une partie de WTP (uniquement les projets war) jusqu’à récemment. En février/ mars 2009, m2eclipse a introduit le gestion des projets EAR et EJB.
Le besoin
Quelle est l’utilité d’avoir un projet à la fois compatible Eclipse-WTP et Maven ? Le réponse est simple : disposer d’un projet fonctionnant aussi bien en local dans l’IDE des développeurs ou des concepteurs d’IHM que dans le cycle automatisé de l’intégration continue. Avec cette solution, je peux donc travailler avec WTP et visualiser les modifications à chaud sur mes différentes pages, voire mes composants si la technologie de mon projet le permet tout en ayant un projet prêt à être exploité dans une software factory type Continuum ou Hudson.
Installation
Pour réaliser les manipulations décrites ci-après, on aura besoin d’une distribution Eclipse incluant les outils de développement JEE disponible sur le site d’eclipse. Il est conseillé d’utiliser une version 3.4.2 voire 3.5 d’eclipse. On aura également besoin du plug-in m2eclipse dont l’installation est décrite ici (on aura recours à la version de développement de m2eclipse (version 0.9.9 à ce jour), celle-ci corrige beaucoup de petits bugs qui rendent le plug-in plus agréable à utiliser). Enfin on devra disposer d’un projet JEE sous WTP et d’un serveur JEE sur lequel déployer ce projet. Pour cet article j’utilise Eclipse 3.5 64 bits (sous MAC OS X 10.5.7) avec WTP 3.1, m2eclipse 0.9.9 et JBoss 5.0.
Début du tutoriel
Nous démarrons ce tutoriel avec 3 projets eclipse WTP : un EAR, un EJB et un WAR. Ces projets se présentent comme le montre l’image suivante.
Les trois projets sont liés entre eux grâce aux fichiers de configuration Eclipse et WTP qui permettent au système de savoir que l’EAR englobe les deux autres et l’EJB et le WAR peuvent utiliser les bibliothèques de l’EAR pour leur compilation. Les projets de mon exemple sont basés sur SEAM mais les étapes décrites dans ce tutoriel sont valable pour tout type de projet JEE. Le petit bonus de l’article pour les Seamiens sera les listes de dépendance maven propre à Seam que je vais donner.
Physiquement, ces trois projets sont matérialisés par 3 arborescences distinctes sur le disque toutes placées dans le dossier de l’espace de travail. Inutile de dire que tout ceci n’est pas du tout dans l’esprit Maven…
Création d’un projet Maven Parent
Première étape nous créons un projet Maven Parent qui va englober nos projets EAR, EJB et WAR. Ce projet permet de regrouper l’ensemble des sous projets (que l’on appelle module) et de définir des paramètres globaux pour tous les modules. Pour créer ce projet parent, cliquez sur « File/New/Project… »
Puis choisissez Maven Project dans la catégorie Maven et cliquez sur Next, un wizard « New Maven Project » s’ouvre :
Vous pouvez passer à l’étape suivante en vérifiant que la case « Create a simple project » est bien décochée.
Dans cette boîte de dialogue, vous êtes invité à choisir un archétype (un modèle pour votre projet). Dans Catalog choisissez Nexus Indexer qui pointe vers une liste plus riche que celle proposée en interne par défaut. Puis dans la zone filtre tapez « pom » pour trouver l’archétype « pom-root ». Sélectionnez-le et cliquez sur « Next ».
Dans cette dernière boîte de dialogue vous donnez un nom à ce projet. Je ne vais pas faire un exposé sur Maven ici, mais vous pouvez donner le nom de votre client au group ID et le nom du projet avec une extension « -parent » ou « -root » pour indiquer qu’il s’agit du projet root. Cliquez ensuite sur « Finish ». Vous obtenez un nouveau projet dans votre workspace. Dans mon exemple « pfm77-parent ».
Création des modules Maven sous le projet parent
De la même façon que nous avons créé le projet parent, nous allons maintenant créer les projets enfants ou modules maven. Cliquez sur « File/New/Project… »
et choisissez maintenant « Maven Module » puis cliquez sur « Next ». Un wizard assez semblable au premier s’ouvre :
Vous allez y indiquer le nom du module ear et le nom du projet Maven parent de ce module (en l’occurrence le projet Maven parent précédemment créé) puis cliquez sur « Next ».
En ayant bien choisi « Nexus Indexer » dans le catalogue, tapez ear dans la zone « filter ». Choisissez l’archétype « ear-jee5″ puis cliquez sur « finish »
Pour créer les module EJB et WAR on aura recours au même wizard. On nommera les nouveaux module avec les extensions « -ejb » et « -war » en choisissant comme projet parent le même que pour l’EAR et en prenant respectivement les artefacts « ejb-jee5″ puis « webapp-jee5″.
A l’issue de ces manipulations, on obtient 4 nouveaux projets dans le workspace :
La structure physique de ces projets est particulière. Sur le disque, dans le dossier workspace, la hiérarchie Maven est respectée : le dossier parent est le seul directement apparent, les autres projets sont des sous dossiers de ce dernier. C’est le premier avantage de m2eclipse : il permet de supporter dans Eclipse des projets imbriqués dans l’arborescence d’un projet existant. Mais c’est loin d’être le seul.
Le travail de m2eclipse
Avant de poursuivre il me paraît intéressant de mettre en lumière les principales fonctionnalités prises en charge par m2eclipse, pour bien comprendre l’intérêt du plug-in et s’épargner de longues heures de bagarre avec lui
1) la gestion de projets arborescent dans Eclipse
Comme on l’a vu au paragraphe précédent, m2eclipse permet à la fois de gérer une arborescence Maven classique tout en en intégrant les sous-projets (ou modules) comme des projets Eclipse classiques. Cette fonctionnalité est aussi active lors de l’import d’un projet Maven dans le workspace soit par la fonction « import Maven project » soit par l’importation depuis un serveur gestionnaire de version (SVN ou CVS). Cette fonction s’opère grâce aux fichiers pom.xml qui permettent à Maven de distinguer les différents projets ou module du projet.
2) La gestion des dépendances Maven au sein d’Eclipse
C’est la fonctionnalité de base de m2eclipse. Le plug-in gère les fichiers pom.xml comme le fait Maven pour récupérer les bibliothèques nécessaires à la compilation et/ou l’exécution des projets. Fini les jar embarqués dans les projets et les méga-octets de jar à commiter vers le serveur de versionning.
3) Le build Maven dans Eclipse
Ca va de soit mais autant le dire un projet m2eclipse dispose du builder Eclipse classique (Java builder) mais également d’un builder Maven ce qui li permet de jouer sur les deux environnements.
4) Une belle interface pour gérer les fichiers pom.xml
Plutôt sympa et complète, cette interface est très intéressante pour contrôler le graphe des dépendances dans un projet. Malheureusement, elle est encore un peu buguée donc nous nous contenterons d’éditer le fichier pom.xml en mode texte dans ce tutoriel.
5) La gestion automatisée de la configuration Eclipse des projets
C’est la fonctionnalité la moins documentée mais une des plus intéressante. Le fait d’ignorer ce point vous promet de longues heures de lutte entre la configuration Eclipse du projet et la configuration automatique de ce dernier générée par m2eclipse (c’est du vécu !). La meilleure illustration de cette fonction sont les projets que nous venons de créer. Ces projets sont issus d’archétypes Maven et n’ont rien à voir avec Eclipse, aussi, les fichiers de configuration Eclipse de ces nouveaux projets (les fichiers .classpath .project et le dossier .settings) ont été générés automatiquement par m2eclipse à l’importation de l’archétype grâce à l’analyse du fichier pom.xml de chaque projet. Si vous modifiez vos fichiers pom.xml (comme on le fera plus loin), m2eclipse mettra à jour ces fichiers de configuration Eclipse pour refléter ces changements. Ainsi, si vous regardez les « Facets » du projet EJB (clic droit sur le projet, properties/project Facets) vous verrez quelque chose comme ça :
M2eclipse a donc automatiquement déduit du fichier pom.xml que ce projet était un projet EJB et a donc automatiquement ajouté cette « facets » au projet. Si jamais vous modifiiez ce paramètre dans Eclipse, m2eclipse écraserait vos modifications au prochain rafraîchissement de la configuration d’où la bagarre évoquée ci-dessus. Cette configuration automatique découle de la détection de la présence du packaging ejb et du plug-in ejb de Maven dans le fichier pom.xml. M2eclipse analyse le paramétrage du plug-in (Maven pas Eclipse) dans le fichier et en déduit la configuration Eclipse correspondante. Le traitement est identique pour les plug-in Maven Ear et War. Alors, ne doit-on donc plus toucher aux propriétés Eclipse des projets concernés ? Pas si simple ! M2eclipse ne peut pas tout générer à partir des fichiers pom.xml. Par exemple, le serveur de déploiement WTP ne sera jamais configuré via m2eclipse : cela n’a pas de sens pour Maven donc pas d’information de ce type dans le fichier pom.xml. Il faut donc examiner attentivement les paramètres générés par m2eclipse pour savoir lesquels vous pouvez ou devez gérer. La bonne nouvelle, c’est que m2eclipse n’écrase pas les fichiers de configuration lors du rafraîchissement mais les met à jour, aussi vos paramètres seront ignorés par le plug-in sans être effacés (sauf s’il s’agit de paramètres gérés par m2eclipse 
). Le plus simple est de ce référer à cette page de la doc m2eclipse pour savoir quels sont les paramètres des différents plugins pris en compte par m2eclipse pour générer la configuration Eclipse du projet. Les paramètres avec une coche verte sont exploités à l’inverse de ceux avec une croix rouge.
Pour conclure sur ce point crucial, il convient également de rester extrêmement vigilant à la mise sous subversion ou cvs d’un tel projet. En effet, on aura intérêt à écarter le versionning de tous les fichiers de configuration éclipse en sachant que des configurations locales seront à recréer sur chaque poste (serveur de déploiement, configuration Seam ou Spring, etc…).
Transvasement
Mais revenons à notre migration WTP vers Maven/WTP. L’étape suivante consiste à copier l’ensemble des fichiers sources, page web et autre fichier de configuration de l’ancienne structure de projet à l’autre. En gros on copiera tout sauf les jar inclus dans la vieille version WTP. Le plus simple est de faire ce transvasement du système de fichier vers Eclipse par drag & drop en se plaçant dans la perspective « resources » qui ne cache pas certains dossiers comme la perspective Java. Pour se faciliter la vie on respectera de préférence la disposition des répertoires par défaut de Maven, cela évitera d’avoir à alourdir les fichiers pom.xml
- Pour le module EAR on déplacera le contenu du META-INF dans src/main/application/META-INF qui contiendra les fichiers de configuration du projet. Le reste du projet se construira avec le fichier pom.xml
- Pour le module EJB, l’ensemble des classes devra être mis dans src/main/java, les fichiers de ressource devant figurer dans le classpath (fichiers properties, dossier META-INF) dans src/main/resources
- Pour le module WAR, on prendra les mêmes dossiers pour les sources et les ressources. Le fichiers du site devront être placé sous src/main/webapp (attention de ne pas rapatrier le dossier lib dans WEB-INF)
Attention à ne pas ramener les fichiers Manifest dans nos nouveaux projets. Ceux-ci peuvent contenir des classpath qui vont perturber notre travail.
Passons maintenant à nos fameux pom.xml
Pom pom pom pom
Sans être un travail symphonique (désolé pour ce moment de détente à mi-chemin de l’article), l’ajustement nos 4 fichiers pom va nécessiter un peu de doigté et de patience (c’est le côté feng-shui de Maven : on tâtonne et on ajuste puis on fini par trouver sans trop savoir comment on y est arrivé ), mas promis, on va y arriver commençons par le commencement
Le Projet Parent
Je ne vais pas détailler la rédaction de mes fichiers : ce serait un peu fastidieux. Je vous propose plutôt de passer en revue le résultat en commençant par les rubriques du fichier :
- Introduction : c’est ici que je défini que c’est un projet de type « pom » qui pilote donc la construction de plusieurs modules
- modules : ici je donne les modules à traiter à ne pas confondre avec les projets que je vais déclarer dans l’EAR
- properties : ici je définis des variables qui me permettront de garder une cohérence dans les version de Jar présentent dans plusieurs modules
- repositories : j’ajoute dans cette section les repositories JBoss me permettant de faire référence à Seam et le repository de java.net me permettant de référencer l’artefact jee5
- dependencyManagement : cette rubrique me permet de déclarer des dépendances présentes dans des sous-modules. En les déclarant ici, je peux fixer leur version une fois pour toute. Pour information la bibliothèque org.ostermiller.utils est un ensemble d’outils assez sympa pour générer et lire des fichiers CSV et qui supporte les particularités du CSV Excel. Plus d’infos sur cette bibliothèque ici.
- build : dans cette section finale, je déclare le plugin de compilation Maven, ce qui me permet de fixer une fois pour toute la version du compilateur Java à employer.
<?xml version="1.0" encoding="UTF-8"?>
<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>cos</groupId>
<artifactId>pfm77-parent</artifactId>
<packaging>pom</packaging>
<version>0.0.1-SNAPSHOT</version>
<name>pfm77-parent Multi Project</name>
<url>http://maven.apache.org</url>
<modules>
<module>pfm77-ear</module>
<module>pfm77-ejb</module>
<module>pfm77-war</module>
</modules>
<properties>
<seam.version>2.0.3.CR1</seam.version>
<jsf.version>1.2_10</jsf.version>
<richfaces.version>3.2.1.GA</richfaces.version>
</properties>
<repositories>
<repository>
<id>jboss</id>
<name>JBoss Repository</name>
<url>http://repository.jboss.org/maven2</url>
<snapshots>
<enabled>false</enabled>
</snapshots>
</repository>
<repository>
<id>jboss-snapshots</id>
<name>JBoss Snapshot Repository</name>
<url>http://snapshots.jboss.org/maven2</url>
<releases>
<enabled>false</enabled>
</releases>
<snapshots>
<enabled>true</enabled>
</snapshots>
</repository>
<repository>
<id>java.net1</id>
<name>Java.Net Maven1 Repository, hosts the javaee-api dependency</name>
<url>http://download.java.net/maven/1</url>
<layout>legacy</layout>
</repository>
</repositories>
<dependencyManagement>
<dependencies>
<dependency>
<groupId>commons-beanutils</groupId>
<artifactId>commons-beanutils</artifactId>
<version>1.8.0</version>
<scope>compile</scope>
</dependency>
<dependency>
<groupId>org.ostermiller</groupId>
<artifactId>utils</artifactId>
<version>1.07.00</version>
<scope>compile</scope>
</dependency>
</dependencies>
</dependencyManagement>
<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>
</project>
Le projet EAR
Dans ce fichier, on peut se débarrasser du plug-in de compilation puisque définit dans le projet Parent. En revanche, on va devoir ajouter toutes les jar du projet et leur version. Les outils de complétion de m2eclipse deviennent indispensable sur ce coup. Faites un clic droit sur le projet, choisissez Maven et « add Maven dependency ». La boîte de dialogue suivante s’ouvre.
Elle vous permet de rechercher dans les repositories Maven pour vous proposer la bibliothèque correspondant à votre recherche et vous permettre de l’ajouter au fichier pom. Au fur et à mesure que vous ajoutez des dépendances, des jar indésirables peuvent s’ajouter à votre projet (des dépendance de dépendance). Vous pouvez les exclure en rajoutant une rubrique exclusion dans le pom ou en utilisant la vue « Dependency Graph » du fichier pom. Cette vue propose un graphe de ce genre :
Si vous souhaitez exclure une bibliothèque, vous pouvez le faire via le menu contextuel de celle-ci en choisissant « Exclude Maven Artefact… ». Attention cette fonctionnalité est buguée dans les version antérieures à 0.9.9. Elle semble à présent donner le traitement attendu. C’est vraiment utile si comme moi, vous n’êtes pas fana de l’édition XML. Pour en revenir au fichier POM de l’EAR voici ses rubriques puis son contenu
- En-tête : je précise qu’il s’agit bien d’un module EAR et je n’oublie pas de pointer sur le projet Maven parent
- Dans les dependencies je n’oublie pas de placer les modules EJB et WAR de mon projet
- Dans la section build j’ajoute le plug-in EAR de Maven dans lequel j’indique le répertoire où stocker les jar du projet et demande au système de générer le fichier application.xml
- Dans la section modules du plugin j’ajoute les modules de mon projet EAR que j’ai défini au début du fichier comme dependencies
<?xml version="1.0" encoding="UTF-8"?>
<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>
<parent>
<artifactId>pfm77-parent</artifactId>
<groupId>cos</groupId>
<version>0.0.1-SNAPSHOT</version>
</parent>
<groupId>cos</groupId>
<artifactId>pfm77-ear</artifactId>
<packaging>ear</packaging>
<version>0.0.1-SNAPSHOT</version>
<name>pfm77-ear JEE5 Assembly</name>
<url>http://maven.apache.org</url>
<dependencies>
<dependency>
<groupId>cos</groupId>
<artifactId>pfm77-ejb</artifactId>
<version>0.0.1-SNAPSHOT</version>
<type>ejb</type>
<scope>compile</scope>
</dependency>
<dependency>
<groupId>cos</groupId>
<artifactId>pfm77-war</artifactId>
<version>0.0.1-SNAPSHOT</version>
<type>war</type>
<scope>compile</scope>
</dependency>
<dependency>
<groupId>org.jboss.seam</groupId>
<artifactId>jboss-seam</artifactId>
<version>${seam.version}</version>
<type>ejb</type>
<scope>compile</scope>
<exclusions>
<exclusion>
<groupId>javax.el</groupId>
<artifactId>el-api</artifactId>
</exclusion>
<exclusion>
<artifactId>javassist</artifactId>
<groupId>javassist</groupId>
</exclusion>
<exclusion>
<artifactId>dom4j</artifactId>
<groupId>dom4j</groupId>
</exclusion>
</exclusions>
</dependency>
<dependency>
<groupId>org.ostermiller</groupId>
<artifactId>utils</artifactId>
</dependency>
<dependency>
<groupId>org.richfaces.framework</groupId>
<artifactId>richfaces-api</artifactId>
<version>${richfaces.version}</version>
<scope>compile</scope>
<exclusions>
<exclusion>
<artifactId>commons-collections</artifactId>
<groupId>commons-collections</groupId>
</exclusion>
<exclusion>
<artifactId>commons-logging</artifactId>
<groupId>commons-logging</groupId>
</exclusion>
</exclusions>
</dependency>
</dependencies>
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-ear-plugin</artifactId>
<version>2.3.2</version>
<configuration>
<version>5</version>
<defaultLibBundleDir>lib</defaultLibBundleDir>
<generateApplicationXml>true</generateApplicationXml>
<modules>
<ejbModule>
<groupId>cos</groupId>
<artifactId>pfm77-ejb</artifactId>
</ejbModule>
<ejbModule>
<groupId>org.jboss.seam</groupId>
<artifactId>jboss-seam</artifactId>
</ejbModule>
<webModule>
<groupId>cos</groupId>
<artifactId>pfm77-war</artifactId>
<contextRoot>PFM77</contextRoot>
</webModule>
</modules>
</configuration>
</plugin>
</plugins>
<finalName>pfm77-ear</finalName>
</build>
</project>
Le projet EJB
On continue avec le POM du projet EJB. Pas grand chose à dire excepté sur le plugin EJB de maven qui nous permet de définir la version des EJB employée (la version 2.1 c’est la version du plug-in de Maven).
<?xml version="1.0" encoding="UTF-8"?>
<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>
<parent>
<artifactId>pfm77-parent</artifactId>
<groupId>cos</groupId>
<version>0.0.1-SNAPSHOT</version>
</parent>
<groupId>cos</groupId>
<artifactId>pfm77-ejb</artifactId>
<packaging>ejb</packaging>
<version>0.0.1-SNAPSHOT</version>
<name>pfm77-ejb JEE5 EJB</name>
<url>http://maven.apache.org</url>
<dependencies>
<dependency>
<groupId>javaee</groupId>
<artifactId>javaee-api</artifactId>
<version>5</version>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>3.8.1</version>
<scope>test</scope>
</dependency>
<dependency>
<groupId>org.jboss.seam</groupId>
<artifactId>jboss-seam</artifactId>
<version>${seam.version}</version>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>org.hibernate</groupId>
<artifactId>hibernate-annotations</artifactId>
<version>3.2.0.ga</version>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>commons-beanutils</groupId>
<artifactId>commons-beanutils</artifactId>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>org.ostermiller</groupId>
<artifactId>utils</artifactId>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>mysql</groupId>
<artifactId>mysql-connector-java</artifactId>
<version>5.1.6</version>
<scope>provided</scope>
</dependency>
</dependencies>
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-ejb-plugin</artifactId>
<version>2.1</version>
<configuration>
<ejbVersion>3.0</ejbVersion>
</configuration>
</plugin>
</plugins>
<finalName>pfm77-ejb</finalName>
</build>
</project>
Le projet WAR
Et pour finir le pom d projet WAR. Notons que pour ce projet nous n’avons pas recours au plugin WAR de Maven, les valeurs par défaut du packaging war nous suffisent. Le plugin permettrait de préciser certains éléments de configuration.
<?xml version="1.0" encoding="UTF-8"?>
<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>
<parent>
<artifactId>pfm77-parent</artifactId>
<groupId>cos</groupId>
<version>0.0.1-SNAPSHOT</version>
</parent>
<groupId>cos</groupId>
<artifactId>pfm77-war</artifactId>
<packaging>war</packaging>
<version>0.0.1-SNAPSHOT</version>
<name>pfm77-war JEE5 Webapp</name>
<url>http://maven.apache.org</url>
<dependencies>
<dependency>
<groupId>javax.servlet</groupId>
<artifactId>servlet-api</artifactId>
<version>2.5</version>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>javax.servlet.jsp</groupId>
<artifactId>jsp-api</artifactId>
<version>2.1</version>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>3.8.1</version>
<scope>test</scope>
</dependency>
<dependency>
<groupId>org.jboss.seam</groupId>
<artifactId>jboss-seam-ui</artifactId>
<version>${seam.version}</version>
<scope>compile</scope>
<exclusions>
<exclusion>
<groupId>org.jboss.seam</groupId>
<artifactId>jboss-seam</artifactId>
</exclusion>
</exclusions>
</dependency>
<dependency>
<groupId>org.jboss.seam</groupId>
<artifactId>jboss-seam-debug</artifactId>
<version>${seam.version}</version>
<scope>compile</scope>
<exclusions>
<exclusion>
<groupId>org.jboss.seam</groupId>
<artifactId>jboss-seam</artifactId>
</exclusion>
</exclusions>
</dependency>
<dependency>
<groupId>org.jboss.seam</groupId>
<artifactId>jboss-seam-pdf</artifactId>
<version>${seam.version}</version>
<scope>compile</scope>
<exclusions>
<exclusion>
<groupId>org.jboss.seam</groupId>
<artifactId>jboss-seam</artifactId>
</exclusion>
</exclusions>
</dependency>
<dependency>
<groupId>org.richfaces.ui</groupId>
<artifactId>richfaces-ui</artifactId>
<version>${richfaces.version}</version>
</dependency>
<dependency>
<groupId>org.richfaces.framework</groupId>
<artifactId>richfaces-impl</artifactId>
<version>${richfaces.version}</version>
<exclusions>
<exclusion>
<groupId>commons-logging</groupId>
<artifactId>commons-logging</artifactId>
</exclusion>
<exclusion>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
</exclusion>
<exclusion>
<groupId>javax.faces</groupId>
<artifactId>jsf-api</artifactId>
</exclusion>
<exclusion>
<groupId>org.richfaces.framework</groupId>
<artifactId>richfaces-api</artifactId>
</exclusion>
<exclusion>
<groupId>javax.servlet</groupId>
<artifactId>servlet-api</artifactId>
</exclusion>
<exclusion>
<groupId>javax.faces</groupId>
<artifactId>jsf-impl</artifactId>
</exclusion>
</exclusions>
</dependency>
</dependencies>
<build>
<finalName>pfm77-war</finalName>
</build>
</project>
Génération de la configuration Eclipse
Après avoir créé tous nos fichiers pom, nous allons demander à m2eclipse de générer les fichiers de configuration Eclipse. Pour ce faire, sur chaque projet on accède au menu contextuel puis on choisit « Maven/Update Projet Configuration » et tous les petits fichiers .claspath, .projects et le dossier .settings de nos projets sont mis à jour.
Premier build Maven et déjà quelques réglages
Nous sommes prêt à lancer notre premier build Maven. Dans le menu contextuel du projet parent (pas l’EAR). On choisit « Run as…/Maven install » ou « Maven package ». Maven se lance et le build échoue… Pas de panique ce problème est dû à un conflit causé par la présence de la résolution Maven dans le workspace. On désactive cette option sur le projet parent (et lui seul) dans le menu contextuel en choisissant « Maven/Disable Workspace Resolution » (je sais, ça se mérite ! La preuve, vous êtes toujours en train de lire). On relance le build et miracle, notre construction Maven aboutit à la génération d’un fichier EAR dans le répertoire target du projet EAR. En ligne de commande, on se placera dans le dossier du projet parent et on tapera « mvn package » pour obtenir le même effet.
Et WTP ?
N’oublions pas qu’on a fait tout ça pour fonctionner sous WTP et Maven en même temps. Nous y sommes presque. Seul petit souci, le fichier aplication.xml de notre EAR WTP ne sait pas demander à Maven de le générer à la volée. Il faudra donc le recopier du dossier target vers le dossier « src/main/application/META-INF » et le refaire à chaque fois que les modules de l’EAR changent (a priori ce n’est pas tous les jours). Et maintenant ? Hé bien, croyez le ou non mais c’est fini et ça marche. Dans la vue serveur d’Eclipse choisissez votre serveur (si vous n’en n’avez pas vous pouvez créer un déploiement local en ajoutant un serveur « local deployer »). Dans le menu contextuel du serveur choisissez « Add remove.. » et ajoutez votre projet.
Cliquez ensuite sur « publish » et tadaaa, votre projet est déployé via WTP (enfin normalement, sinon recommencez le tuto du début :- ) ). Seule ombre au tableau, le déploiement génère un répertoire WEB-INF dans la racine de l’EAR reprenant le dossier lib du module war. Le module war comprend bien son lib, c’est juste une duplication dû à un bug eclipse. A priori rien de gênant pour une exécution en local
Conclusion
Comme on l’a vu m2eclipse demande pas mal de connaissances pour être utilisé dans un contexte WTP. Cela dit, il reste un outil très puissant hors de ce besoin d’intégration si particulier mais tellement pratique. Concernant Seam et Maven, JBoss travail activement à simplifier la tâche des développeurs. En effet JBoss tools 3.1 devrait inclure des extensions permettant de travailler avec m2eclipse depuis un projet Seam et Seam 3.0 devrait être beaucoup facile à utiliser à travers Maven.
A suivre donc…
