Maven? kesako ?

Depuis que le monde java existe, il est continuellement accompagné de nombreux outils. Parmi ceux-ci, on compte les compilateurs (javac), les générateurs de documentation (javadoc), etc…

Il existe une autre catégorie d’outils: les outils d’aide à la construction.

Le plus ancien et le plus vénérable était Ant.  je dis était car il n’est plus trop au goût du jour. En effet, à sa suite sont arrivés bien des concurrents parmi lesquels on peut trouver, maven, gradle, sbt (pour Simple Build Tool), et la liste s’allonge tous les jours.

Celui qui a le plus marqué ces 10 dernières années et qui domine encore le marché de la construction d’application, car utilisé de façon industrielle est Maven.

Maven va au delà du simple outil de construction, il possède un cycle de vie qui colle à celui de la fabrication d’un logiciel. La simple commande mvn est capable, dans le désordre:

  • de compiler,
  • de gérer les dépendances de version de composants,
  • d’exécuter des tests unitaires(UT),
  • des tests  d’intégration (INT)
  • et des test End-to-End (E2E).

Elle est même capable de prendre en main la création d’une release, se chargeant de la gestion du numéro de version, de la compilation des dépendances, et du packaging dans le but de la livraison, sous plusieurs formes pilotées qui plus est: JAR, WAR et/ou EAR. il sera même capable de construire la documentation du code basée sur javadoc ou même docbook, de construire un site de livraison et même, si vous lui demandez avec les formes,  proposera un packaging en ZIP des sources du projet.

Bref, vous le comprenez, Maven est L’outil du jour pour la construction de logiciel Java.

Même si quelques concurrent arrivent doucement à sa hauteur, comme graddle, aujourd’hui seul maven est capable de couvrir un tel gamme de prestation.

Premier shoot à la pom(.xml)

Il est intéressant d’observer de plus près la constitution de ce fichier, il constitue la recette de fabrication de votre application. on y trouvera les nom, description et version de votre logiciel, mais aussi, ses dépendances avec le monde extérieur, ainsi que la recette de fabrication permettant d’aller du fichier source (*.java de façon générale) vers le JAR, le WAR ou même l’EAR.

JAR? WAR ? EAR ?

Quels sont ces acronymes barbares ? Quelques rappels s’imposent:

  • JAR : Java ARchive, c’est le packaging de base de la livraison d’un quelconque logiciel ou partie de logicel basé sur le langage java. On pourra trouvé en son sein des classes java compilée (*.class), des fichiers de resources divers (*.xml, *.properties, *.txt, etc…) et aussi et surtout la classe contenant si besoin le fameux main() pour la lancement de votre programme, dans le cas d’un logiciel autonome. Le JAR peut (et c’est souvent le cas) contenir une API (Application Programming Interface) constituant les points d’entrées d’une librairie apportant nombre de fonctionalité. Les plus connues dans le monde java sont log4j, ainsi que les apache-commons.
  • WAR : Web ARchive: c’est le cran au dessus du JAR, on trouvera comme dans les jar, des classes java, des resources, mais aussi et surtout une structure adapté au service d’applications orientée web. on pourra trouver des répertoires specifique au web tels que WEB-INF/ et META-INF/ contenant eux-mêmes des fichiers de configuration à destination du serveur Java qui sera chargé lors du déploiement de servir l’application sur internet ou l’intranet d’une entreprise.
  • EAR : Enterprise ARchive; ce type d’archive est destinée à contenir un ensemble de services ou d’applications qui sont elles-mêmes packagées au format WAR. C’est une commodité de déploiement. Elle contiendra également des informations de contexte destinée au serveur, et permettant de lui expliquer les liens entre les différentes applications et services qu’elle contient.

Pourquoi ce rappel ? Parce que justement, le petit fichier Project Maven, le fameux pom.xml, permet de préciser, entre autres, la cible de packaging de votre projet.

La structure du fichier obéit a quelques règles syntaxiques de base. Vous trouverez ci-dessous un modèle de fichier type.

<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/xsd/maven-4.0.0.xsd">
  <modelVersion>4.0.0</modelVersion>
  <groupId>[project_group_id]</groupId>
  <artifactId>[project_articfact_id]</artifactId>
  <version>[project_version: ex. : 0.0.1-SNAPSHOT]</version>
  <packaging>[jar/war/ear/pom]</packaging>
  <name>[project_name]</name>
  <description>[project_description]</description>
</project>

Voila comment se décrit un projet à l’aide de Maven.

En exemple, attaché à cet article, vous trouvez dans ce fichier pom_sample.xml décrivant une application web  orientée REST, plus d’information sur les possibilités d’un « simple pom » au niveau de la description administrative du projet. L’intérêt ne sera que visible lors de la mise en intégration continue (ou construction continue), où les liens vers le repository de sources ou l’outil de suivi des bugs auront tous leurs sens.

Atardons nous sur les principaux champs de ce pom.xml:

[project_group_id] et [project_artifact_id] sont les premiers piliers de Maven, ils vont permettre d’identifier clairement votre projet. Dans le cas ou ce projet ne serait qu’une partie d’une application impliquant plusieurs composant, accompagné du tag de version ([project_version]) va permettre une gestion fine des dépendances.

C’est la première mission de maven.

Un projet réalisé sous maven, est en fait dénommé un artifact, il possède son propre identifiant, l’artifactId. Ce projet fait obligatoirement partie d’un groupe, cela permettant un classement des composants d’un même projet, ou d’un ensemble de projets. Il est par habitude composé principalement du nom de la société, de l’association, de la fondation ou de l’organisation à l’origine du logiciel. dans notre cas, nous partirons sur com.webcontext.apps pour tous nos exemples dans la suite de cet article. Le groupe en question sera également identifié par un groupId.

Note:
Le groupId est souvent similaire au nom du package java de base de votre application. par exemple si votre application est contenu par un package de base « com.masociete.monprojet », le groupId pourra être « com.masociete.apps » et l’artifactId « monrpojet ».

BUILD

La deuxième mission de maven est l’aide à la construction de l’application. le premier élement a spécifier serait donc une cible de compilation. Implicitement, maven nécessite la présence d’un JDK afin de pouvoir compiler les sources java. Maven n’apportant pas lui-même ces outils de base. Aussi, vous devez, par maven, indiquer une cible de version de ce JDK.

cela se fera via l’aide d’un ensemble de plugin de maven, spécialisés sur certaines missions.

Attardons nous un peu sur le premier :

Attribut Valeur
groupId org.apache.maven.plugins
artifactId maven-compiler-plugin
version 3.1

Et oui, même les plugins sont gérés et identifiés par Maven.

déclarons dans le fichier pom.xml que nous souhaitons utiliser un compilateur issu de la version 1.7 de java:

<build>
  <plugins>
    <plugin>
      <groupId>org.apache.maven.plugins</groupId>
      <artifactId>maven-compiler-plugin</artifactId>
      <version>3.1</version>
      <configuration>
        <target>1.7</target>
        <source>1.7</source>
        <encoding>UTF-8</encoding>
      </configuration>
    </plugin>
  </plugins>
</build>

C’est simple, net et précis. l’opération de build doit s’appuyer sur a configuration de compilation indiquant une version 1.7 du JDK pour le compilateur.

Nous spécifions également l’encodage des fichiers, que nous fixons ici à « UTF-8 », cela pour des raisons évidentes de compatibilité cross-plateforme.

Maintenant, si nous exécutons notre premier commande maven via la commande mvn, nous pourrons lancer l’une ou l’autre des étapes de construction de notre application, appelées dans le jargon maven, des goals.

Les deux premiers qui nous intéressent pour le moment sont « clean » et « build« .

  • clean : permet de nettoyer l’espace de travail de toute ancienne trace de compilation, ce afin de partir sur des base seine pour la nouvelle compilation. Notons en passant que un nouveau répertoire va faire son apparition à l’exécution de cette première commande, target. c’est dans ce répertoire que seront construit tous les éléments de notre projet pour préparer plus tard le packaging en JAR, WAR ou EAR.
  • compile : c’est l’opération de compilation faisant appel au compilateur java dans la version de compatibilité indiquée (ici 1.7). javac sera lancé par maven avec toutes les options nécessaires pour atteindre ce but.

Compilation

Lançons nous :

c:\> mvn clean
c:\> mvn compile

Nous avons doc nettoyé et compilé nos sources. Enfin, pour le moment, cela est fictif car nous n’avons pas encore de sources. D’ailleurs a ce propos, regardons la structure d’un projet maven:

_ [mon_projet]   # repertoire de base du projet
  |_ src              # sources du projet découpées en deux groupes
  |  |_ main          # les sources a proprement parlé du code du projet
  |  |  |_ java       # - les classes java dans leurs packages   
  |  |  |_ resources  # - les resources additionnelles comme les  *.properties, *.xml, ...
  |  |  |_ webapp     # - les fichiers composant les UI (html, css, images, javascript)
  |  |_ test          # le code des tests unitaires, intégration et E2E.
  |  |  |_ java       # - les parties java pour l'exécution de ce tests
  |  |  |_ resources  # - les éventuelles ressources nécessaires (données de test)
  |_ target           # l'espace réservé à la compilation et au packaging
  |_ pom.xml          # le fichier de description du projet maven. 

Voila en quelques lignes décrite la structure standard d’un projet Maven.

Il nous reste a créer un premier vrai projet. je vous propose la réalisation d’un projet Web basé sur une mise en oeuvre de la Technologie REST propre à java, JAX-RS décrit dans la spécification standard JSR-311.

Mais en premier lieu, il nous faudra comprendre le fonctionnement de base sur un projet simple, à base de JAR.

La suite au prochain numéro.

To be continued… (comme disent nos amis outre-atlantique)

Publicités