Dans cet article, nous allons voir les différents composants du pom.xml et comment chaque partie du pom joue un rôle crucial en fournissant les informations nécessaires aux autres classes présentes dans le projet.

Introduction

POM signifie “Project Object Model“.
POM comprend trois mots, et que chaque mot a sa propre signification :

Project : C’est le conteneur logique de tout logiciel/caractéristique où chaque fonctionnalité est mise en œuvre.
Object : Chaque projet comprend différents objets tels que des classes, des méthodes, des variables définies par l’utilisateur, etc ..
Modèle : Le modèle est une vue abstraite de tout projet et objet, c’est-à-dire qu’il contient les informations sur l’aspect des projets/objets.

Maintenant, supposons que nous réunissions les trois éléments (Project, Object et Model). Dans ce cas, on peut observer que le POM contient toutes les informations nécessaires requises par le projet et les différents objets associés au projet.

Quelques points importants

Le POM contient un fichier de configuration, des informations sur les dépendances, leurs versions, des informations sur le dépôt, l’organisation, le/les développeurs, les licences et toutes les autres informations cruciales pour le programme.
Le POM contient toutes les informations concernant le processus de construction sous forme de configuration de plugin.
POM contient une réponse sur le QUI, le QUOI et le OÙ des projets.

Ci-dessous se trouve un POM montrant les différentes sections.
La section ci-dessous est prise sur le site officiel de Maven :

<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 https://maven.apache.org/xsd/maven-4.0.0.xsd">
  <modelVersion>4.0.0</modelVersion>
  <!-- The Basics -->
  <groupId>...</groupId>
  <artifactId>...</artifactId>
  <version>...</version>
  <packaging>...</packaging>
  <dependencies>...</dependencies>
  <parent>...</parent>
  <dependencyManagement>...</dependencyManagement>
  <modules>...</modules>
  <properties>...</properties>
  <!-- Build Settings -->
  <build>...</build>
  <reporting>...</reporting>
  <!-- More Project Information -->
  <name>...</name>
  <description>...</description>
  <url>...</url>
  <inceptionYear>...</inceptionYear>
  <licenses>...</licenses>
  <organization>...</organization>
  <developers>...</developers>
  <contributors>...</contributors>
  <!-- Environment Settings -->
  <issueManagement>...</issueManagement>
  <ciManagement>...</ciManagement>
  <mailingLists>...</mailingLists>
  <scm>...</scm>
  <prerequisites>...</prerequisites>
  <repositories>...</repositories>
  <pluginRepositories>...</pluginRepositories>
  <distributionManagement>...</distributionManagement>
  <profiles>...</profiles>
</project>

La version actuellement supportée de POM est 4.0.0 que vous pouvez trouver dans la balise <modelVersion>.

Le strict minimum

L’exemple du POM ci-dessous est le strict minimum pour tout projet (le projet n’inclut aucune dépendance, tout est codé à partir de zéro).
Le groupId, l’artifactId et la version rendent chaque projet unique. Une combinaison de groupId, artifactId, et version est comme une adresse pour tout projet.

<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 https://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>com.nicolas.myapp</groupId>
<artifactId>my-app</artifactId>
<version>0.0.1</version>
</project>

Les différentes sections du POM

Les tags basiques

Prenons l’exemple d’un système de suivi des véhicules, qui contiendra différents services tels que le service d’embarquement des véhicules, le service de réservation des véhicules et le service d’administration. Dans cet exemple, nous supposons que l’entreprise pour laquelle nous travaillons souhaite avoir un groupId différent pour chaque projet.

groupId :

Il n’y a pas de règle fixe pour définir groupId. Cela dépend du développeur ou de l’organisation, si elle veut regrouper différents services sous un projet ou différents projets sous une organisation.

Dans notre exemple, vous pouvez nommer le groupId comme com.trackingvehicle. Il n’y a pas de règle fixe pour nommer un groupId.
Il est généralement unique parmi toutes les organisations et tous les projets. C’est un conteneur pour tous les services relevant d’un même projet.
groupId n’a pas besoin d’être séparé par des points, mais c’est une bonne pratique de l’avoir séparé par des points.
Si vous enregistrez un projet dans le dépôt Maven (local ou global), chaque mot séparé par un point agira comme un répertoire. Dans notre exemple, le projet se trouvera sous com/trackingvehicle.

artifactId :

artifactId est le nom des services ou des modules associés au projet.
Dans notre exemple, onboarding-service, booking-service, et admin-service seront le nom de artifactId.
Il est unique pour chaque groupId.
Si nous sauvegardons les services dans le dépôt Maven, alors la base de code sera :

onboarding-service    -> com/trackingvehicle/onboarding-service
booking-service       -> com/trackingvehicle/booking-service
admin-service         -> com/trackingvehicle/admin-service