Apache Maven

Apache Maven (couramment appelé Maven) est un outil de gestion et d'automatisation de production des projets logiciels Java en général et Java EE en particulier. Il est utilisé pour automatiser l'intégration continue lors d'un développement de logiciel. Maven est géré par l'organisation Apache Software Foundation. L'outil était précédemment une branche de l'organisation Jakarta Project.

Apache Maven

Informations

Développé par	Apache Software Foundation
Première version	13 juillet 2004
Dernière version	3.9.9 (18 août 2024)
Dépôt	github.com/apache/maven
Écrit en	Java
Système d'exploitation	Multiplateforme
Environnement	Machine virtuelle Java
Formats lus	Maven metadata (d)
Formats écrits	Maven metadata (d)
Type	Automate de construction Gestionnaire de paquets
Licence	Licence Apache 2.0
Site web	maven.apache.org

L'objectif recherché est de produire un logiciel à partir de ses sources, en optimisant les tâches réalisées à cette fin et en garantissant le bon ordre de fabrication.

Il peut se comparer au système make sous Unix ou à l'outil Ant.

Maven utilise un paradigme connu sous le nom de Project Object Model (POM) afin de décrire un projet logiciel, ses dépendances avec des modules externes et l'ordre à suivre pour sa production. Il est livré avec un grand nombre de tâches prédéfinies, comme la compilation de code Java ou encore sa modularisation.

Un élément clé et relativement spécifique de Maven est son aptitude à fonctionner en réseau. Une des motivations historiques de cet outil est de fournir un moyen de synchroniser des projets indépendants : publication standardisée d'information, distribution automatique de modules jar. Ainsi en version de base, Maven peut dynamiquement télécharger du matériel à partir des dépôts logiciels connus. Il propose ainsi la synchronisation transparente de modules nécessaires.

Maven1 et Maven2 ont été développés en parallèle mais les versions ultérieures sont fondées sur la structure de la deuxième version. Les parties suivantes de l'article traitent en priorité Maven2. Une version 3 de Maven est sortie le 8 octobre 2010. La fin de support de la version 2 a été actée le 18 février 2014.

Project Object Model (POM)

Chaque projet ou sous-projet est configuré par un POM qui contient les informations nécessaires à Maven pour traiter le projet (nom du projet, numéro de version, dépendances vers d'autres projets, bibliothèques nécessaires à la compilation, noms des contributeurs, etc.). Ce POM se matérialise par un fichier pom.xml à la racine du projet. Cette approche permet l'héritage des propriétés du projet parent. Si une propriété est redéfinie dans le POM du projet, elle recouvre celle qui est définie dans le projet parent. Ceci introduit le concept de réutilisation de configuration. Le fichier pom du projet principal est nommé pom parent. 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.

Convention plutôt que configuration

Maven impose une arborescence et un nommage des fichiers du projet selon le concept de Convention plutôt que configuration. Ces conventions permettent de réduire la configuration des projets, tant qu'un projet suit les conventions. Si un projet a besoin de s'écarter de la convention, le développeur le précise dans la configuration du projet.

Voici une liste non exhaustive des répertoires d'un projet Maven :

• /src : les sources du projet
• /src/main : code source et fichiers source principaux
• /src/main/java : code source
• /src/main/resources : fichiers de ressources (images, fichiers annexes, etc.)
• /src/main/webapp : webapp du projet
• /src/test : fichiers de test
• /src/test/java : code source de test
• /src/test/resources : fichiers de ressources de test
• /src/site : informations sur le projet et/ou les rapports générés à la suite des traitements effectués
• /target : fichiers résultat, les binaires (du code et des tests), les packages générés et les résultats des tests

Cycle de vie

Les buts (goals en anglais) principaux du cycle de vie d'un projet Maven sont dans l'ordre :

1. compile
2. test
3. package
4. install
5. deploy

L'idée est que, pour n'importe quel but, tous les buts en amont doivent être exécutés sauf s'ils ont déjà été exécutés avec succès et qu'aucun changement n'a été fait dans le projet depuis. Par exemple, quand on exécute mvn install, Maven va vérifier que mvn package s'est terminé avec succès (le jar existe dans target/), auquel cas cela ne sera pas ré-exécuté.

D'autres buts sont exécutables en dehors du cycle de vie et ne font pas partie du cycle de vie par défaut de Maven (ils ne sont pas indispensables). Voici les principaux :

• clean
• assembly:assembly
• site
• site-deploy
• etc.

Ils peuvent néanmoins être rajoutés au cycle de vie via le POM.

Gestion des dépendances

Dans l'outil Maven, la gestion des dépendances s'appuie sur deux notions :

• l'héritage
• les relations transitives (ou transitivité)

La notion de relation transitive est implémentée pour la relation "dépend de" et l'ensemble projet Java.

Exemple : Soit trois projets (A, B, C), si A dépend de B, et B dépend de C, alors A dépendra de C.

Par défaut dans Maven, la transitivité est configurée en automatique. Cette configuration peut générer des contraintes avec les projets volumineux :

• l'inclusion de jars dans les EAR
• l'inclusion de versions non-désirées
• la présence de dépendances pour différentes versions à différents niveaux de la transitivité (un projet A dépend d’un projet C.x et d'un projet B, et ce dernier dépend du projet C.y)
• une perte d'informations (des dépendances effectives, par exemple) et la présence de dépendances inutiles à d'autres projets.

Dans l'attente d'une amélioration du plugin, cette option est désactivable en configurant l’option provided.

Référentiel (ou entrepôts)

Un autre apport de l'outil Maven est son organisation des projets et plugins. Maven dispose de plusieurs référentiels à plusieurs niveaux. Le but du référentiel est de rendre disponible aussi bien les plugins utilisés ou envisagés de l’être que les projets générés par Maven. On peut bien sûr y installer des projets pour les utiliser (sans qu’ils ne soient générés par Maven). Il y a trois référentiels :

• Un au niveau de la machine du développeur, appelé repository local, il inclut tout ce que le développeur a utilisé et a développé.
• Un au niveau du site Maven qui contient l’ensemble des plugins. Il est en augmentation continue. Il est ouvert à tout le monde, en conséquence des mises à jour pourraient être incohérentes ou incompatibles avec d’autres.
• Pour éviter ceci, il y a un troisième référentiel (facultatif) qui peut être déclaré au niveau de l’entreprise ou la structure utilisant Maven, il joue l’intermédiaire entre les deux premiers référentiels, il inclut les plugins (⇒ maîtrise des versions et des mises à jour) et les projets (les rendant accessible à l’ensemble des développeurs).

Pour créer un référentiel pour l’entreprise (ou un référentiel commun en général), on peut utiliser les protocoles ftp, scp, file et http.

Remarque : le plugin fourni pour le protocole ftp peut poser des problèmes car il n'est pas encore au point.

Pour installer un jar dans le référentiel (sans qu’il ne soit un projet maven), il faut bien générer le POM avec lui. Sans cela Maven essaye de se connecter dans les différents référentiels pour le chercher d'où une réelle perte de temps vu que le jar n’est pas supposé être présent dans ces référentiels.

Une dernière remarque, de taille : dans le référentiel, il y a une structure bien définie et inchangeable (qui permet à Maven de trouver son chemin), où les jar et les projets sont organisés selon le groupId, artifactId puis la version.

Donc une fois une déclaration faite (dépendance ou autre), Maven cherche dans l’emplacement suivant :

{emplacement Repository}/groupId/artifactId/version

Les noms des packages, eux, sont comme suit :

{artifactId}-{version}.{package}

Et à l’opposé du répertoire "target" où on peut définir le nom de notre package, il n’est pas permis de changer les noms ou la structure des packages sous peine de non-reconnaissance de package et donc de "BUILD FAILED".

Rapports

Les rapports générés par Maven portent notamment sur :

• les dépendances du projet
• les résultats des tests lancés, incluant:
  • des statistiques sur les résultats
  • le pourcentage d’efficacité de ces tests
• le pourcentage de code testé
• la complexité du code
• le respect des normes de codage

Plugins

Les plugins permettent l'ajout de fonctionnalités. Ces plugins sont disponibles sur le site de Maven, ou, à défaut, peuvent être développés. Pour utiliser un plugin, il suffit de le déclarer dans le POM.

Il est à noter que la déclaration est héritée par défaut. La déclaration se fait d’une manière simple : groupId (si aucun n’est déclaré, il prend celui par défaut org.apache.maven), artifactId et éventuellement la version (sinon, c’est la dernière version qui est utilisée).

• Exemple d'installation d'artifactId dans pcm-fo^{[à définir]}

set JAVA_HOME=C:\Program Files\Java\jdk1.6.0_38<br />
set M2_HOME=C:\dev\maven\apache-maven-3.0.4-bin\apache-maven-3.0.4<br />
set PATH=%JAVA_HOME%/bin;%M2_HOME%/bin;%PATH%<br />

pause
call mvn install:install-file -Dfile=solr-webapp-3.4.0.war -DgroupId=org.apache.solr -DartifactId=solr-webapp -Dversion=3.4.0 -Dpackaging=war
pause
call mvn install:install-file -Dfile=jodconverter-core-3.0-beta-4.jar -DgroupId=org.artofsolving.jodconverter -DartifactId=jodconverter-core -Dversion=3.0-beta-4 -Dpackaging=jar
pause
call mvn install:install-file -Dfile=parsley-flex4-2.4.1.swc -DgroupId=org.spicefactory -DartifactId=parsley-flex4 -Dversion=2.4.1 -Dpackaging=swc
pause
call mvn install:install-file -Dfile=spicelib-util-3.0.0.swc -DgroupId=org.spicefactory -DartifactId=spicelib-util -Dversion=3.0.0 -Dpackaging=swc
pause
call mvn install:install-file -Dfile=spicelib-reflect-3.0.0.swc -DgroupId=org.spicefactory -DartifactId=spicelib-reflect -Dversion=3.0.0 -Dpackaging=swc
pause
call mvn install:install-file -Dfile=legacy-spicelib-utils-2.5.0.swc -DgroupId=org.spicefactory -DartifactId=legacy-spicelib-utils -Dversion=2.5.0 -Dpackaging=swc
pause
call mvn install:install-file -Dfile=popup-1.9.swc -DgroupId=com.adobe.cairngorm -DartifactId=popup -Dversion=1.9 -Dpackaging=swc
pause
call mvn install:install-file -Dfile=popupParsley-1.9.swc -DgroupId=com.adobe.cairngorm -DartifactId=popupParsley -Dversion=1.9 -Dpackaging=swc
pause
call mvn install:install-file -Dfile=validation-1.13.swc -DgroupId=com.adobe.cairngorm -DartifactId=validation-1.13 -Dversion=1.13 -Dpackaging=swc
pause
call mvn install:install-file -Dfile=cairngorm-integration-0.11.swc -DgroupId=org.spicefactory -DartifactId=cairngorm-integration -Dversion=0.11 -Dpackaging=swc

Après cette déclaration, lors du lancement d’une tâche, Maven vérifie sa présence dans le référentiel local. S’il ne trouve pas le plugin, il se connecte alors au référentiel central pour le télécharger. En cas d'échec de récupération, on termine l’exécution avec un message d’erreur (on peut éviter ceci et demander à Maven de continuer et de donner le résultat du traitement –avec les messages d’erreurs- à la fin).

Maven et Eclipse

Eclipse permet de générer des packages, mais ces derniers ne respectent pas la structure de Maven et ne sont pas non plus installés dans le référentiel. Cela implique que sans l’utilisation d’un outil externe, il faut installer manuellement tous les packages générés.

Un plugin Maven pour Eclipse est disponible, permettant à Eclipse d’utiliser Maven en arrière-plan et donc d'utiliser Eclipse et Maven conjointement.

Ceci permet d’avoir des projets Maven générés et stockés dans le référentiel.

Il permet notamment de dépendre de projets qui sont dans le référentiel, et donc on n’a pas besoin de les importer sous Eclipse comme c’est le cas dans les outils existant. Le classpath est généré par Maven.

Par contre son utilisation comporte quelques lacunes.

Si on lance la commande qui génère le classpath ‘mvn eclipse:eclipse’ à partir d’un POM parent, alors l’ensemble des modules doivent être présents dans l’espace de travail. La dépendance est faite à l’intérieur de cet espace, et pour avoir une dépendance à partir du référentiel, il faut lancer la commande pour chaque module.

Un autre problème (actuellement sans solution), porte sur l’héritage quand on ne respecte pas la hiérarchie dans les répertoires.

Remarques

• Dans le POM, le chemin d’accès au POM du module est défini dans le tag module, et donc on peut utiliser des ../ pour aller à des répertoires qui sont au même niveau (une structure en plan).
• Dans le cas d’une structure en plan, le plugin Eclipse ne reconnaît pas le POM parent, car par défaut il cherche dans les répertoires au-dessus (et a priori impossible de le changer).
• Ce plugin permet à Eclipse de rajouter Maven comme un outil externe, au même titre que Ant.

Intégration continue

Voici une liste non exhaustive des moteurs d'intégration continue qu'il est possible d'utiliser conjointement avec Maven :

• Apache Continuum
• CruiseControl
• Hudson/Jenkins

Analyse de la qualité du code

Voici une liste non exhaustive des plates-formes d'analyse de la qualité du code source qu'il est possible d'utiliser conjointement avec Maven :

• SonarQube

Annexes

Articles connexes

• Gradle

Liens externes

• (en) Site officiel
• Un diaporama sur Maven 2.1 et ses développements futur