mardi 29 mars 2011

Software : Gestion des plugins dans le projet





          Pour permettre de rendre le système évolutif, il sera possible de fournir dans un répertoire les plugins de HomeAutomateCore.

Les plugins seront représentés sous forme de jar. L'application se chargera au démarrage de "loader" dynamiquement les classes. Pour l'instant les plugins ne peuvent qu'embarquer des managers, mais il sera possible d'embarquer de nouveaux mediators ou encore de nouvelles unités.

Ici un exemple de Plugin (plugin de contrôle de température de la maison)



Règle d'écriture des plugins (Projet Java Simple JAVA tirant une dépendance vers HomeAutomateCore (pour les interfaces).




Et il faudra au minimum une classe qui étendra AbstractManager (du Core) et implémentera les interfaces nécessaires. Dans ce greffon HeatManager.java




Ici, on remarque qu'on implémente IMediatorAware ce qui signifie que dès qu'un mediateur recevra un message, le système routera le message vers ce manager (par l'intermédiaire d'un IDomoticMessage)

L'interface IUnitAware permet quant à elle de recevoir les changements de propriétés sur toutes les unités.

Ces 2 interfaces imposent des méthodes :

    onMessage : permettra d'implémenter ce que l'on veut sur la réception d'un message
    onEvent : idem.

L'interface IManager est obligatoire (implémentation du commentaire du plugin, url, status, mode de démarrage, nom ..)

Une fois le plugin terminé : Export du projet sous forme de jar que l'on colle dans le répertoire indiqué dans la table de paramètre sous la clé pluginDirectory.


samedi 26 mars 2011

Software : Et si on discutait avec notre système domotique ?

      


Quoi de neuf : Google Chrome 11 Béta qui intègre le speech recognition. Intéressant, après avoir essayer plusieurs softs : Dragon, Ibm, finalement un nouveau se présente à la porte et au miracle pas d'autre soft à installer que le navigateur, en plus l'api est directement proposée dans HTML 5 :




      L'idée est donc simple, un textfield html jouera le rôle d'écouter les entrées, puis on redirige le texte reconnu vers une action struts qui sera routée à HomeAutomateCore et plus précisément au manager reconnaissance vocale.

Je vous laisse télécharger chrome pour essayer, mais les résultats sont convaincants et surtout sans apprentissage interminable, bref à intégrer pour pousser le test.

La page de test : 

jeudi 24 mars 2011

Software : Et si on faisait parler notre futur système domotique ?

    L'idée est de rendre communiquant le système, même lorsque l'on est pas devant son écran, portable ...
Donc se faire prévenir par le système que quelqu'un est entré dans l'allée, ou encore qu'un pic de consommation électrique est anormal, tout cela peut nous intéresser.

Je me suis essayé à plusieurs, des softs gratuits avec du copier /coller, des utilitaires en mode ligne de commande, le tts virginie de windows .... bref, toujours à passer par un logiciel tiers à installer sur le PC.

Je suis donc allé voir chez Google et leurs magnifiques services web, et je suis tombé sur Google Translation


Avec une simple URL, on peut se faire dicter du texte dans toutes les langues.


Avantage :


                 Une phonétique plus que séduisante ;)
                 Pas de logiciel à installer en local.
                 Rapide.
                 Choix dans les langues.


Inconvénient : 


                 Connection Internet requise pour traduire.




Allez on y va .... Google Traduction en 1 minute 
Je veux écouter le texte "Monsieur, vous prendrez bien un verre de whisky ! "
Rien de plus simple : faites un copier/coller de cette url dans votre navigateur préféré (N'oubliez pas le son !)

http://translate.google.fr/translate_tts?q=Monsieur, vous prendrez bien un verre de whisky


Pour faire du speech en anglais, il faut ajouter un paramètre dans la request :
Ex : 


http://translate.google.fr/translate_tts?tl=en?q=Baboons are eating some bananas


tl=en pour anglais
tl=fr pour français.
tl=es pour espagnol ...


Implémentation dans le code java :


J'ai donc créé un JDBManager ( qui permet d'ajouter des logs, infos, installation, warning et talk) talk permet non seulement d'écrire dans le journal de bord mais en plus d'appeler un autre manager VocalManager qui va se charger d'aller chercher la traduction de code (Enum) à traduire. Ce dernier se base sur un paramètre la locale de notre application (le multilinguisme est prévu). 

Dans le JDBManager , on a donc la méthode talk qui reçoit en paramètre la classe voulant "talker", un code I18N pour le message, et une liste de paramètres (Au passage fonctionnalité JAVA5)
On pourrait donc passer un message du type 'startSystem %s in %s', new Date(), new Home()
rappel le code passé en paramètre est purement une clé, elle sera traduite à l'aide de notre table i18n lorsqu'on voudra consulter le JDB ou lorsque l'on veut faire parler notre système.

voyons voir la méthode talk du vocalManager :


1. On commence par récupérer dans la table des paramètres la locale (par défaut fr_FR si non renseignée) J'utilise une Enum qui est exploitée dans le parameterManager, Exemple de l'Enum, la valeur par défaut est fournie dans le constructeur.

2.On récupère la traduction du code à annoncer. Si le code n'est pas trouvé dans la table i18n, on retournera le code fourni en entrée.

3.On récupère ensuit le service Google dans les paramètres, il est possible d'utiliser un autre service, dans ce cas on mettra un enregistrement dans la table de paramètre avec comme clé googleSpeech. Par défaut c'est donc notre translate.google.... à notre dans cette url par défaut un %s juste après tl, ce % sera substitué par la locale récupérée.

4.On utilise l'API Apache HttpClient, pour contruire notre requête. ne pas oubliez le User-Agent à positionner ici par défaut à Mozilla, sinon vous allez avoir un belle erreur 403 Forbidden.
Au passage les snippets à ajouter dans le pom :

  <dependency>
<groupId>org.apache.httpcomponents</groupId>
<artifactId>httpclient</artifactId>
<version>4.1</version>
</dependency>
<dependency>
<groupId>httpcomponents-httpcore</groupId>
<artifactId>jakarta-httpcore</artifactId>
<version>4.0-alpha2</version>
</dependency>


5. Enfin, on éxecute notre requête et on récupère un InputStream qui sera consommé par un Player MP3 récupéré également à l'aide de ce snippet, et c'est tout !

<dependency>
<groupId>de.huxhorn.sulky</groupId>
<artifactId>de.huxhorn.sulky.3rdparty.jlayer</artifactId>
<version>1.0</version>
</dependency>


Une capture de la table de notre JDB :


Et notre table I18N : 


qui contient une clé i18n, une locale et une traduction.


Notre table des paramètres : 




Et vouala, nos futurs managers (Light, Temperature, Consommation) auront à portée de main ce vocalManager en cas de message à faire passer.

Promis j'attaque la prochaine fois un manager Domotique (RFXCOM, ARDUINO ,...)

Software : Avancée dans le socle

Avancée sur les Managers/Dao de base du socle :


           I18N (Permet l'internationalisation des messages du JDB)
           JDB (Journal de bord permet de stocker les infos système)
           Parameter (Permet de récupérer/sauvegarder des paramètres)


    A noter que le projet à changé de nom : il s'appelle HomeAutomateCore il fournira des services mais pas d'IHM, un autre projet IHM HomeAutomateGUI sera créé, cela permet d'encore plus découpler le Front du Back Office). Tout ceci est bien sur "comité" sur le SVN.

Software : Incorporation de Spring Framework




Et si on faisait un peu d'injection de dépendances dans notre projet ?
Rappel : l'idée est d'injecter les objets que l'on souhaite dans d'autres objets (seule contrainte, le respect des interfaces).

Un injecteur bien connu est SPRING. Toutes les injections se font par fichier xml. Quelle utilité allez vous me dire ?


Imaginez un manager d'alarme qui a besoin d'écrire dans le journal de bord de l'application. Ce n'est pas au manager d'alarme d'insérer directement le message. Ce travail est délégué à un manager Journal de Bord, et ce dernier n'est peut être pas encore implémenté (les api oui mais pas l'implémentation) et bien avec Spring on pourra injecter un mock dans le manager d'Alarme, cela permettra de tester : 


                   Notre code java d'alarme sans l'implémentation final du JDB.
                   De ne pas retoucher le code mais seulement la configuration, pour faire un test d'intégration avec le journal de bord. pas mal non ? 


voyons voir comment cela se passe...


Tout d'abord, un coup de snippet maven dans notre pom.xml: 



  <dependency>
<groupId>org.springframework</groupId>
<artifactId>spring</artifactId>
<version>2.5.6</version>
<optional>false</optional>
</dependency>


Puis on modifie notre web.xml pour que Spring s'infiltre dans notre application :
Voici donc les seules lignes à ajouter : 



 <context-param>
<param-name>contextConfigLocation</param-name>
<param-value>/WEB-INF/applicationContext.xml</param-value>
</context-param>


<listener>
<listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
</listener>



      Maintenant on va faire un tour dans le fichier applicationContext.xml 
On y déclarera tous nos "beans" SPRING, tous pures POJO les uns que les autres. Le scope pourra être précisé pour chaque bean (singleton=une seule instance ou prototype=nouvelle instance à chaque besoin)
Pour nos managers le mode singleton est adapté (pas la peine de créer x instances du même manager), cela tombe bien c'est la config par défaut.

Exemple : 


J'ai déclaré 2 managers (id=parameterManager et id=jdbManager)
dans la classe ParameterManager j'ai 2 attributs ( dao et jdbManager) et bien j'indique à Spring d'injecter dans cette classe parameterDao dans l'attribut dao et jdbManagere dans jdbManager.


Spring va alors chercher un bean nommé parameterDao dans sa configuration, l'instancier et le placer dans parameterManager (qu'il aura lui aussi instancié)




Au niveau code, tout ce que l'on a à faire lorsque que l'on veut utiliser parameterManager c'est de passer par le chargeur de contexte Spring, et oui il faut bien que Spring applique toute la mécanique par la dessus. On est donc obligé de passer par le container SPRING pour obtenir les beans.

Faire un new ParameterManager ne fonctionnera pas, les attributs resteront désespérément null.
Il faut faire la chose suivante :


ServletContext servletContext = servletConfig.getServletContext();
WebApplicationContext wac = WebApplicationContextUtils
.getRequiredWebApplicationContext(servletContext);

ParameterManager pm = (ParameterManager) wac.getBean("parameterManager");

Il existe plusieurs technique de chargement du contexte Spring, par chargement url (on est pas forcément dans un contexte WEB).

Voici une première facette de SPRING appelée IOC (Inversion Of Control), mais Spring offre d'autres fonctionnalités que nous utiliserons pas la suite (Orienté Aspect, Intégration, Batch, ...) je vous invite à consulter le site.





http://www.springsource.org/

mercredi 16 mars 2011

Software : Quel ORM ? Hibernate

Incorporation d'Hibernate dans le projet.



Pour l'installation, rien de plus facile, ajout du Snippet dans le pom.xml (voir Post sur Maven)

Rappel : Hibernate est l'un des nombreux ORM disponibles (Object Relation Mapping) il va permettre de faire le lien entre nos objets JAVA et les tables de la base de données MYSQL. Et ainsi par la suite nous apporter nombre fonctionnalités de requêtes/ recherches / insert, simplifiées. Il gérera également 2 caches permettant d'accélérer les traitements. il sera également possible de persister notre héritage, faire des associations 1-n, n-n, n-1, projections... On aurait pu utiliser le simplissime DB4O (Base de données purement Objet), mais bon l'envie d'un MYSQL .... 

Le lien pour les curieux  http://www.hibernate.org/ & http://www.db4o.com/

Bon, Maven a fait le travail pour nous (n'oubliez pas d'ajouter la dépendance avec Mysql pour le driver Jdbc)

Il y a donc comme tout bon framework un fichier de configuration appelé hibernate.cfg.xml. Il permet (en résumé) d'indiquer les identifiants de connection à la base de données, le driver utilisé*, le dialect à utiliser (Mysql, Oracle, DB2, ....). ainsi que des liens vers nos objets à persister.


* Hibernate n'est pas trés bavard pour les requêtes qu'il passe, on voit les requetes (dans le format hql Hibernate Query Language), mais les valeurs ne sont pas visibles. Pour combler cela on peut utiliser un log4jdbc ou encore p6spy qui s'intercale entre le drivers JDBC et Hibernate, il suffira de préciser dans la property <property name="connection.driver_class">com.mysql.jdbc.Driver</property>

Voici le mien : 

Un truc bien pratique (en vert pâle) la property hibernate.hbm2ddl.auto positionnée à update permet à hibernate de créer la table sur la base de définition de mapping de notre objet, pratique lorsque l'on part d'une base vide, cela évite de se taper un DDL de création.
En bleu, un premier mapping, celui des paramètres de l'application (répertoires, valeurs par défaut, ....) et oui faut bien les persister.


<?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE hibernate-configuration PUBLIC
        "-//Hibernate/Hibernate Configuration DTD 3.0//EN"
        "http://www.hibernate.org/dtd/hibernate-configuration-3.0.dtd">
<hibernate-configuration>


<session-factory>
<property name="connection.url">jdbc:mysql://localhost/homeautomate</property>
<property name="connection.username">homeautomate</property>
<property name="connection.driver_class">com.mysql.jdbc.Driver</property>
<property name="dialect">org.hibernate.dialect.MySQLDialect</property>
<property name="connection.password">homeautomate</property>
<property name="hibernate.hbm2ddl.auto">update</property>


 <property name="transaction.factory_class">org.hibernate.transaction.JDBCTransactionFactory</property>
    <!--  thread is the short name for
      org.hibernate.context.ThreadLocalSessionContext
      and let Hibernate bind the session automatically to the thread
    -->
    <property name="current_session_context_class">thread</property>
    
    <!-- this will show us all sql statements -->
    <property name="hibernate.show_sql">true</property>


<!-- mapping files -->
<mapping resource="test/Parameter.hbm.xml" />


</session-factory>


</hibernate-configuration>




Vouala pour le fichier de configuration, jetons un oeil à notre Parameter.hbm.xml
On indique en rouge le package où se trouve la classe à mapper. En vert le nom de notre Objet (ici Parameter)
Toujours un id (ici purement technique et non fontionnel) il identifiera notre objet (Attention à ce propos, il faudra redéfinir l'equals et le hashcode dans notre objet afin de tenir de cet id, Hibernate l'utilisant pour son cache et différencier les objets).
Generator Class précise comment est géré l'ID (ici un simple incrément, on aurait pu utiliser une SEQUENCE ou un compteur logiciel, voir la doc pour ça).
Et enfin on précise les champs de notre objet que l'on va vouloir persister (ps: si le nom des colonnes est identique au nom des attributs, il n 'y rien à faire), il faudra préciser le type d'attribut (string, integer, date, ...). En bleu ici le fait que la clé soit unique.



<?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE hibernate-mapping
   PUBLIC "-//Hibernate/Hibernate Mapping DTD//EN"
   "http://hibernate.sourceforge.net/hibernate-mapping-3.0.dtd">

<hibernate-mapping package="com.homeautomate.parameter">
   <class name="Parameter" >
      <id name="id" type="int">
         <generator class="increment"/>
      </id>

     <property name="cle" type="string" unique-key="cle">
      <property name="valeur" type="string"/>
      <property name="commentaire" type="string"/>
      
   </class>
</hibernate-mapping>



Et c'est tout !!!
En démarrant notre Serveur Hibernate vérifie si la table existe (Ps je n'ai pas préciser le nom de la table puisqu'elle aura le même nom que ma classe), si elle existe, il vérifiera les évolutions pour mettre à jour le schéma, si elle n'existe pas, la table sera créée. Attention pour créer les tables, il faut être précis sur les types des colonnes (not null, ... ) et surtout ! (J'ai cherché, il existe de mots réservés sur les dialectes ex: value en Mysql est prohibé comme nom de colonne, ou encore sequence en ORACLE, donc méfiance avec le nom des attributs.


Surprise dans la log de démarrage du Serveur : 


INFO  DatabaseMetadata - table not found: Parameter
INFO  DatabaseMetadata - table not found: Parameter
DEBUG SchemaUpdate - create table Parameter (id integer not null, cle varchar(255), valeur varchar(255), commentaire varchar(255), primary key (id), unique (cle))
INFO  SchemaUpdate - schema update complete

Et si je regarde le résultat dans MySQLAdministrator : 




Utilisation en java : 


Exemple : je veux récupérer un paramètre : 


Après avoir fait un parameterManager, une Dao interface, et une DaoHibernateIlmpl (voir conception), on m'oblige à implémenter une méthode public Parameter getParameter(ParameterEnum key) qui retourne une interface Parameter et qui prends en paramètre une ParameterEnum de nom key.


package com.homeautomate.dao;

import com.homeautomate.parameter.Parameter;

import constant.ParameterEnum;

public class ParameterDaoHibernateImpl extends
AbstractDaoHibernateImpl<Parameter> implements IParameterDao {

public Parameter getParameter(ParameterEnum key) {
Parameter param = new Parameter();
param.setCle(key.name());
return findByQbeUnique(param);
}

}

Commentaires : 


    J'étends une AbstractDaoHibernateImpl qui me permettra de récupérer des méthodes sympa, m'affranchir de l'ouverture et fermeture des sessions. Vous noterez également au passage un peu de généricité JAVA5 (<Parameter>). J'utilise ici un findByQbe (Query by example). En fait ici on va rechercher dans la table paramètres tous les paramètres qui ont comme clé la valeur de key passée en paramètre.
J'ai suffixé par unique la Qbe parceque je considère que la clé est unique. Allez remontons d'un niveau, allons voir dans l'Abstract du dessus :


package com.homeautomate.dao;


import java.util.List;


import org.hibernate.Criteria;
import org.hibernate.SessionFactory;
import org.hibernate.cfg.Configuration;
import org.hibernate.classic.Session;
import org.hibernate.criterion.Example;


public class AbstractDaoHibernateImpl<T> implements AbstractDao<T> {


private static Configuration cfg;
private static SessionFactory sessionFactory;


private void initializeConfiguration() {
if (cfg == null) {
cfg = new Configuration();
cfg.configure("com/homeautomate/hibernate.cfg.xml");
sessionFactory = cfg.buildSessionFactory();


}


}


public List<T> findByQbe(Object entity) {
initializeConfiguration();
Session session = sessionFactory.openSession();
try {
Criteria crit = session.createCriteria(entity.getClass());
crit.add(Example.create(entity));
return crit.list();
} catch (Exception e) {
throw new RuntimeException(e);
} finally {
session.close();
}


}


public T findByQbeUnique(Object entity) {
initializeConfiguration();
Session session = sessionFactory.openSession();
try {
Criteria crit = session.createCriteria(entity.getClass());
crit.add(Example.create(entity));
return (T) crit.uniqueResult();
} catch (Exception e) {
throw new RuntimeException(e);
} finally {
session.close();
}
}
}


En rose (dans la méthode findByQbe classique) j'utilise la méthode list sur le criteria Hibernate. alors que dans la méthode findByQbeUnique j'utilise (en orange) uniqueResult(), On oblige hibernate à ne retourner qu'une seule valeur (Si on en est sur). Vous noterez l'initializeConfiguration qui va lire le fichier de conf.


Il est possible de faire plein d'opération sur les criteria.


Vouala.
Simple non ? Toutes ces méthodes sont présentes dans l'interface AbstractDao qui seront à implémenter si on utilise un autre ORM (OJB) ou un truc plus brutal genre JDBC.


A noter qu'Hibernate implémente l'API Java JPA (Java Persistance API)
JPA



Software : Partage de fichier avec GoogleCode





Les projets peuvent bénéficier de serveurs de synchronisation de sources (CVS, SVN, ...). Le but étant de faire de la gestion de configuration et donc :

  •  d'être capable de versionner les évolutions de notre code.
  •  d'identifier les écarts entre 2 versions
  •  de réaliser des branches de développement.
  •  de "merger" ces branches, de les comparer, etc...


mais également de permettre le travail collaboratif sur un projet.

Pour cela il est possible de s'installer un serveur SVN ou CVS à la maison, mais GoogleCode en place un à disposition :


Ce site nous permettra d'héberger gratuitement notre projet à hauteur de 2go de code source (il y a déjà de quoi faire).

Pour cela on clique sur Project Hosting on GoogleCode, il faut avoir au préalable créer un compte Google.



Un petit icone vert (Create a new project) permet d'ouvrir son espace de stockage.
Après avoir répondu à toutes les questions, l'espace est ouvert. On peut maintenant passer sous Eclipse.
Il faut maintenant installer (Update Software du menu help) le client SVN.

Il faut ensuite passer en vue SVN Repository Explorating et créer un lien vers le repo Google (ici le tronc version actuelle installée chez moi et une branche version en cours de refactoring de ce blog).
Ps : l'url est fournie par Google.


Puis faire un clic droit sur notre projet/Team/Share the project et choisir le repo précédemment créé.
Ou alors si vous voulez récupérer le projet faire un Checkout sur le projet HomeAutomateCore

Vous pouvez donc récupérer mon projet sur votre Eclipse (S'il y a des motivés pour bosser sur le projet why not )


Vouala


Software : Mise en place de MAVEN dans le cadre du projet







Avec Java et ses milliers de librairies (.jar) disponibles sur le net, il devient vite fastidieux de télécharger sur divers sites les .jar et de les assembler dans le classpath.
Cela survient généralement lorsqu'on partage un projet, effectivement, on récupère le code source du projet et on s'aperçoit rapidement que des dépendances sont manquantes.
Pire encore, on télécharge une librairie et celle ci est dépendante d'une autre (Insupportable).

Du coup est arrivé MAVEN (dépot de librairies jar), on pourrait assimiler ça à serveur de dépot Linux (apt-get xxx ou rpm -install ....). 
Pour spécifier les librairies à utiliser, on aura juste à créer un fichier pom.xml au sein de notre projet et d'y spécifier à l'aide de balises <dependency> les dependances nécessaires au bon fonctionnement du projet.

Plus d'informations sur le site Maven d'Apache. Bien entendu, Maven ne fait pas que cela, une multitude de plugins, goals sont disponibles.

Donc conclusion voici le fichier pom.xml de notre projet, où pour l'instant nous tirons quelques dépendances

Comme SpringFramework permettant de faire de l'injection (En Vert)
Comme Hibernate notre ORM (En rouge)
Comme Log4j notre loggeur préféré (En bleu)
Comme le runtime Apache (pour notre serveur d'appli) (En mauve)
Comme le driver JDBC Mysql pour atteindre notre base (En orange)

La partie Build permettra de construire notre fichier WAR qui sera déployé sur notre Serveur Tomcat.

Le fichier se trouve à la racine de notre projet : 



Voici son contenu : 

<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>HomeAutomateCore</groupId>
<artifactId>HomeAutomateCore</artifactId>
<packaging>war</packaging>
<name>Coeur HomeAutomate</name>
<version>1.0</version>
<dependencies>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring</artifactId>
<version>2.5.6</version>
<optional>false</optional>
</dependency>


<dependency>
<groupId>org.freemarker</groupId>
<artifactId>freemarker</artifactId>
<version>2.3.16</version>
<scope>provided</scope>
</dependency>


<dependency>
<groupId>org.hibernate</groupId>
<artifactId>hibernate</artifactId>
<version>3.1.3</version>
</dependency>


<dependency>
<groupId>log4j</groupId>
<artifactId>log4j</artifactId>
<version>1.2.16</version>
</dependency>


<dependency>
<groupId>org.apache.tomcat</groupId>
<artifactId>servlet-api</artifactId>
<version>6.0.29</version>
</dependency>


<dependency>
<groupId>mysql</groupId>
<artifactId>mysql-connector-java</artifactId>
<version>5.1.14</version>
</dependency>


</dependencies>


<build>
<directory>target</directory>
<outputDirectory>target/classes</outputDirectory>


<testOutputDirectory>target/test-classes</testOutputDirectory>
<sourceDirectory>src</sourceDirectory>
<testSourceDirectory>test</testSourceDirectory>
<resources>
<resource>


<directory>resource</directory>
</resource>
</resources>
<testResources>
<testResource>
<directory>testresource</directory>
</testResource>
</testResources>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-war-plugin</artifactId>
<version>2.1.1</version>
<configuration>
<warSourceDirectory>${basedir}/WebContent</warSourceDirectory>
<attachClasses>true</attachClasses>


<archive>


<manifest>


<addClasspath>false</addClasspath>
</manifest>
</archive>
</configuration>
</plugin>
<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>




Une fois le fichier pom déposé, il faut maintenant exécuter une commande MAVEN qui va interpréter le fichier pom et commencer à récupérer les librairies manquante et compiler le projet. Pour cela on passe dans le menu External Tool Configuration d'Eclipse (Au passage je vous conseille d'installer le plugin MAVEN dans Eclipse par le menu updates Software du menu Help).


On lancera donc la commande mvn.bat (Après avoir téléchargé maven)
puis en paramètre les goals suivants : 

            clean validate install eclipse:eclipse compile war:inplace

Je vous laisse consulter le site maven pour le détail de chaque Goal, juste 2 infos : eclipse:eclipse permet d'intégrer les modifications dans l'IDE Eclipse (Classpath) et war:inplace permet de recopier les lib téléchargées dans le répertoire WEB-INF/LIB.

Capture d'écran :


Après avoir cliqué sur Run, Maven va télécharger du dépot les librairies nécessaires et les placer dans un cache local (variable M2_REPO).

Je constate maintenant que mes librairies sont référencées depuis le M2_REPO :


Et vouala.