xms-ovh-dokuwiki

Maven est un gestionnaire de build, qui remplace (et encapsule) un ancien : ANT.

Il permet donc de builder (compiler) les src, effectuer des test unitaire ou d'intégration, de packager l'application, déployer, et de l'exécuter.

Il offre aussi plein d'autre possibilité pour peux que vous sachiez l'utiliser.

Mais comme il est très puissant, il est aussi très complexe …

Très simple : récupérer et extraire le zip depuis le site de maven. Mettre le chemin de mvn.exe dans %PATH%, et le tour est joué. Ouvrir un invité DOS ou shell et tapper :

   mvn -version

Si bien installé, alors vous devriez voir, la version de maven, de java, de l'os, …

Chaque projet maven est constitué, à sa racine, d'un fichier (type makefile) nommé pom.xml. Il définit/paramètre un ensemble d'actions liées au projet, parmi la copie de fichier, la compilation, le lancement de l'application, le lancement des tests, le prétraitement, le nettoyage des fichiers générés.

La plupart du temps, le pom.xml est configuré selon un système d'arborescence standard qui fait que :

• tout ce qui va être compilé ou préparé pour la compilation, ou bien généré pour l’exécution se trouve dans le dossier target. (Les opérations de nettoyage et de reconstruction s’en retrouvent facilitées. un seul dossier à effacer).
• le packaging se fait dans un dossier nommé .m2 situé en général dans un des dossier utilisateur de l'OS (C:\Users\xavier\.m2).

Le gros avantage de Maven est qu’il apporte la récupération automatique de dépendance (comprendre librairies), à partir de repositories (sur internet ou en intranet). On citera notamment le repo “maven central”. Une dépendance correspond en fait à un package (jar, war, plugin), accompagné de d'autres fichiers qui le décrivent et qui décrivent ses dépendances. Dès lors on comprend bien que finallement, chaque projet possèdera une arborescence de dépendances.

Le repo local, c'est ce dont j'ai parlé plus tôt : C:\Users\xavier\.m2. C'est le dossier qui contient toutes les dépendance et projet dont vous disposez.

La grande puissance de Maven est de savoir rapatrier toutes les dépendances de chaque projet (librairies et plugins jar). Ces librairies et plugins sont situés sur des dépôts distants. (le plus connu est maven central, qui est le repositiory distant par défaut je crois).

Maven réalise automatiquement le rapatriement des dépendances requise par le projet dans le repo local (si elles ne sont pas déjà présentes), et le projet les référera. Le repo local est situé par défault dans c:\Users\<User1>\.m2\repository, on y retrouve :

• toutes les dépendances déjà récupérées par maven. Ce soit des artifacts (comprendre librairies), soit des plugins
• tous les projets qu'on a généré avec maven

Une fois récupérée dans le repo local l'arborescence de chaque dépendance suivra le même pattern : <.m2_folder>/repository/<groupId>/<artifactId>/<version>

Dans les 2 cas, ces artifacts sont toujours générés avec des fichiers XML les décrivant, dont notamment le fichier d’extension .pom

Les dépendances sont toujours stockées avec des fichiers XML les décrivant, notamment le fichier d’extension .pom. Ces descriptions embarque leur dépendances (librairies jars + xml + pom), qui dépendent à leur tour d’autres jars …  maven analyse leur dépendance et va les chercher si besoin. Cette notion de transitivité, fait qu'une dépendance peut dépendre d'une autre, traduit l’existence, pour chaque projet, d’un arbre de dépendance. Une commande plus bas indique comme l’afficher avec maven.

Remarque : Toutes les dépendances référencées dans son projet ne doivent pas forcément être utilisées de la même manière dans le processus de build ou lors de l'exécution de l'artéfact. Pour se faire, on peut associer à chaque dépendance un scope (utilisé pour la compilation, ou juste l’éxécution, ou juste les tests).

• Les artéfacts : composants identifiés de manière unique : (groupId,artifactId,version)

• Le principe de convention over configuration : standardisation de la structure arborescente par défaut des projets

• Les phases des cycles de vie d'un projet : les étapes de construction d'un projet sont standardisées. Les principales phases définies par Maven sont, dans l'ordre du cycle de built :
  1. validate : validation avant la compilation
  2. compile : compilation (java)
  3. test : test unitaire
  4. package :
  5. install : install le jar,war,ear, ou autre et les fichiers xml dont le pom.xml dans le dossier .m2 (repo local)
  6. deploy :
  7. clean : phase en dehors du cycle de build, pour effacer tout ce qui a été généré par maven)
  8. site : phase en dehors du cycle de build, pour générer un site web documentant le projet

Deux règles sont importantes à retenir concernant les phases :

1. Chaque phase peut être une séquence de sous-phases, comme par exemple clean qui est en fait = pre-clean → clean → post-clean
2. La demande d'exécution d'une phase nécessite l'exécution de toute les phase amont. Par exemple si on tappe “mvn install”, alors, les phases validate, compile, test, package seront jouées avant et dans cet ordre.

• Type de packaging : un projet (artifact) maven possède un type de packaging (war, jar, ejb, rar, pom, maven-plugin, etc…) ; suivant ce type, les goals des plugins sont associées à certains des cycles de vie.

• Les dépôts : (le dépôt local et les dépots distant), stockent les artéfacts.

• Les plugins : comme les dépendances du repo local, ce sont artifacts, qui contiennent des .jar qui peuvent être exécuté par maven.

• L’héritage d'un artificats : pom parent (voir spring boot, par exemple)

• Les profils : dev, prod, ou autres

• Les scopes : Notion de portée de chaque dépendances, par défaut : compile
  1. compile : la dépendance est utilisable par toutes les phases et à l'exécution. C'est le scope par défaut
  2. provided : la dépendance est utilisée pour la compilation mais elle ne sera pas déployée car elle est considérée comme étant fournie par l'environnement d'exécution. C'est par exemple le cas des API fournies par un serveur d'applications
  3. runtime : la dépendance n'est pas utile pour la compilation mais elle est nécessaire à l'exécution. C'est par exemple le cas des pilotes JDBC
  4. test : la dépendance n'est utilisée que lors de la compilation et de l'exécution des tests. C'est par exemple le cas pour la bibliothèque utilisée pour les tests unitaires (JUnit ou TestNG pas exemple) ou pour les doublures (Easymock, Mockito, …)

Lire http://maven.apache.org/guides/mini/guide-attached-tests.html