Tout ce que vous vouliez savoir sur Maven - "Projet Java de A à Z"

Bonjour à tous, chers amis. Je voudrais tout de suite m'excuser : je me souviens que j'avais promis d'écrire un article une fois par semaine. N'a pas fonctionné. Je n’ai tout simplement pas eu le temps de m’asseoir et d’écrire correctement, mais je ne veux pas le faire de telle ou telle façon. Je ne me plaindrai pas des raisons, car je n’en ai pas besoin et cela ne vous intéresse certainement pas. Le projet n'est pas mort, il était en stase :) On continue ! Et le matériel d'aujourd'hui est dédié à Maven.

Parlons de Maven

Vous devez d’abord l’installer. Bien sûr, comme j'ai un Mac, je ne peux afficher que l'installation pour un Mac. C'est juste de la malchance. Je l'ai installé il y a longtemps, vous devrez donc le faire vous-même :)

Pourquoi avons-nous besoin de Maven ?

Maven est un outil de création de projets, aux côtés de Gradle et Ant. Juste parce que je vais l'utiliser dans JRTB (JavaRush Telegram Bot), je souhaite vous mettre au courant. De nos jours, aucun projet n'est créé sans un système d'assemblage, car il nous simplifie la vie plusieurs fois. Ceci permet:

• • extraire toutes les bibliothèques nécessaires (en termes d'outils d'assemblage - dépendances (c'est-à-dire dépendance)) ;
• • déterminer exactement comment le projet doit être assemblé et dans quoi (par exemple, voulons-nous le collecter dans WAR ou JAR ou JAR exécutable) ;
• • placer la version du projet en un seul endroit afin qu'elle soit indiquée lors du montage ;
• • décrire le projet et son cycle de vie ;
• • ajouter ce qu'on appelle des plugins (version traditionnelle du mot anglais Plugin) ;
• • publier les bibliothèques dans un référentiel partagé afin que d'autres projets puissent les extraire en tant que dépendances.

En général, il fait beaucoup de choses, et elles sont toutes utiles. Je dirai ceci : pour les ingénieurs débutants, il n'est pas nécessaire de connaître toutes les fonctionnalités d'un bout à l'autre. Ici, comme avec git, il est important de comprendre les bases et les concepts généraux. C'est ce que nous ferons. Pour nous, Maven commence par un fichier XML à la racine de notre projet appelé pom.xml . Nous ferons tout en pratique, nous allons donc d'abord créer notre premier projet dans la communauté JavaRush. Pour tout faire judicieusement, j'utiliserai un modèle pour le référentiel , où les éléments de base que j'ai décrits une fois sur JR sont déjà configurés . Pour créer, allez dans le référentiel avec le modèle et cliquez sur le bouton Utiliser ce modèle : En conséquence, nous avons le premier référentiel de notre communauté :) Nous téléchargeons le projet localement. Pour ce faire, à travers l'idée, allez dans File -> New -> Project from Version Control . Dans la fenêtre qui apparaît, saisissez un lien vers le projet sur Github (le résultat sera meilleur si tout le monde crée le même projet séparément et suit toutes les étapes avec moi) : Cliquez sur Cloner , et le projet est cloné .

pom.xml est à la tête de tout

Tout ce dont vous avez besoin se trouve dans pom.xml. Toutes les informations sur le projet, son développeur et sur quel référentiel distant le projet est stocké. Au début, nous nous intéressons aux blocs suivants : <project/> - c'est le bloc principal, qui contient toutes les informations sur le projet. Tous les autres y seront explicitement ou transitivement. À l'intérieur de la balise d'ouverture, il est écrit quelque chose comme ceci :

<project xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xmlns="http://maven.apache.org/POM/4.0.0"
        xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
                     http://maven.apache.org/xsd/maven-4.0.0.xsd">

Et par-dessus tout, la ligne suivante est également écrite dans tous les pomniks (l'argot est censé provenir de pom.xml :)).

<modelVersion>4.0.0</modelVersion>

Mais cela devient ensuite plus intéressant : nous décrirons comment nous identifions le projet décrit dans notre mémorial. En prenant ma bibliothèque comme exemple, je vais la décrire, puis nous l'ajouterons à notre mémoire, au projet nouvellement créé :

<groupId>com.github.romankh3</groupId>
<artifactId>image-comparison</artifactId>
<version>4.4.0-SNAPSHOT</version>
<packaging>jar</packaging>

<name>Image Comparison</name>

L'essentiel ici :

• • groupId est l'identifiant de l'organisation de développement ou de l'ingénieur individuel. Il s'agit généralement du domaine dans l'ordre inverse. A titre d'exemple, le compte romankh3 sur Github est décrit ici. Il est très important. Disons que pour l'écosystème Spring, c'est com.springframework . De cette façon, vous pouvez distinguer le projet original du fork de quelqu'un d'autre ou simplement par la coïncidence du nom du projet.
• • artifaceId est déjà le nom d'un projet spécifique décrit dans cette mémoire.
• • version : la version de ce projet. Tout ici est clair comme le jour : ajout de nouvelles fonctionnalités, correction des anciennes, refactorisation ou apport d'autres modifications - augmentation de la version.
• • packaging - nous décrivons ici comment Maven doit assembler notre projet. Soit en Jar, soit en War, ou quelques autres .
• • nom - voici un nom plus agréable pour le projet.

Il y a encore certaines choses qu'il n'est pas du tout nécessaire de remplir - Maven fonctionnera sans elles - mais si vous devez publier la bibliothèque pour un usage public, cela vaut vraiment la peine de les ajouter. Quelles sont ces choses?

• • chemin d'accès au référentiel du projet, à partir duquel il peut être téléchargé

  <url>https://romankh3.github.io/image-comparison/</url>

• • la licence sous laquelle ce projet est distribué. De plus, il peut y en avoir plusieurs, et vous devez donc le définir de cette façon :

  <licenses>
   <license>
     <name>The Apache Software License, Version 2.0</name>
     <url>http://www.apache.org/licenses/LICENSE-2.0.txt</url>
   </license>
  </licenses>

• • des informations sur les développeurs qui ont créé/créent le projet :

  <developers>
   <developer>
     <id>romankh3</id>
     <name>Roman Beskrovnyi</name>
     <email>roman.beskrovnyy@gmail.com</email>
   </developer>
  </developers>

• • le bloc scm, qui décrit comment accéder au projet :

  <scm>
  <connection>git@github.com:romankh3/image-comparison.git</connection>
  <developerConnection>git@github.com:romankh3/image-comparison.git</developerConnection>
   <url>https://github.com/romankh3/image-comparison</url>
  </scm>

Après avoir décrit les informations générales, nous pouvons ajouter un bloc avec des dépendances :

<dependencies>
   <dependency>
       <groupId>org.mockito</groupId>
       <artifactId>mockito-core</artifactId>
       <version>2.26.0</version>
       <scope>test</scope>
   </dependency>
   <dependency>
       <groupId>org.junit.jupiter</groupId>
       <artifactId>junit-jupiter-api</artifactId>
       <version>5.5.2</version>
       <scope>test</scope>
   </dependency>
<dependency>
   	<groupId>com.github.romankh3</groupId>
   	<artifactId>image-comparison</artifactId>
   	<version>4.3.0</version>
<scope>test</scope>
</dependency>
</dependencies>

Ici, j'ai ajouté deux bibliothèques pour les tests : elles sont toujours nécessaires. Comme vous l'avez peut-être déjà remarqué, les dépendances ont un Scope - scope. Dans notre cas , test est spécifié , ce qui signifie que nous ne verrons tout simplement pas cette dépendance dans le code principal. Ensuite, pour que tout soit beau, vous pouvez utiliser une balise distincte pour afficher les versions <properties/> :

<properties>
   <mockito.version>2.26.0</mockito.version>
   <junit.version>5.5.2</junit.version>
   <image.comparison.version>4.3.0</image.comparison.version>
</properties>

Le bloc de dépendances peut donc être mis à jour à l'aide de la construction ${PROPERTY_NAME} :

<dependencies>
   <dependency>
       <groupId>org.mockito</groupId>
       <artifactId>mockito-core</artifactId>
       <version>${mockito.version}</version>
       <scope>test</scope>
   </dependency>
   <dependency>
       <groupId>org.junit.jupiter</groupId>
       <artifactId>junit-jupiter-api</artifactId>
       <version>${junit.version}</version>
       <scope>test</scope>
   </dependency>
   <dependency>
       <groupId>com.github.romankh3</groupId>
       <artifactId>image-comparison</artifactId>
       <version>${image.comparison.version}</version>
       <scope>test</scope>
   </dependency>
</dependencies>

Vient ensuite un grand bloc <build/> , qui contient un bloc <plugins/> important , avec lequel vous pouvez personnaliser le processus de construction. Vous pouvez ajouter un ou plusieurs plugins à l'intérieur du bloc <plugins/> , comme ceci :

<build>
   <plugins>
       <plugin>
           <groupId>org.apache.maven.plugins</groupId>
           <artifactId>maven-source-plugin</artifactId>
           <version>3.2.0</version>
           <executions>
               <execution>
                   <id>attach-sources</id>
                   <goals>
                       <goal>jar</goal>
                   </goals>
               </execution>
           </executions>
       </plugin>
   </plugins>
</build>

Ici, vous pouvez voir que j'ai ajouté deux plugins - maven-source-plugin et maven-javadoc-plugin . Chacun des plugins possède des paramètres, des attributs (paramètres) qui peuvent être définis, personnalisant ainsi les plugins. Cela sera intéressant pour nous à l’avenir. Pour l'instant, rappelons-nous et passons à autre chose. De la même manière que pour les dépendances, nous mettrons les versions du plugin dans <properties/> . Sur cette base, vous pouvez créer la mémoire suivante :

<project xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xmlns="http://maven.apache.org/POM/4.0.0"
        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>com.github.javarushcommunity</groupId>
   <artifactId>maven-demo</artifactId>
   <version>1.0-SNAPSHOT</version>
   <packaging>jar</packaging>

   <name>Maven Demo Project</name>

   <url>https://github.com/javarushcommunity/maven-demo/</url>

   <properties>
       <mockito.version>2.26.0</mockito.version>
       <junit.version>5.5.2</junit.version>
       <maven.compiler.source>1.8</maven.compiler.source>
       <maven.compiler.target>1.8</maven.compiler.target>
       <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
       <source.plugin.version>3.2.0</source.plugin.version>
   </properties>

   <dependencies>
       <dependency>
           <groupId>org.mockito</groupId>
           <artifactId>mockito-core</artifactId>
           <version>${mockito.version}</version>
           <scope>test</scope>
       </dependency>
       <dependency>
           <groupId>org.junit.jupiter</groupId>
           <artifactId>junit-jupiter-api</artifactId>
           <version>${junit.version}</version>
           <scope>test</scope>
       </dependency>
   </dependencies>

   <build>
       <plugins>
           <plugin>
               <groupId>org.apache.maven.plugins</groupId>
               <artifactId>maven-source-plugin</artifactId>
               <version>${source.plugin.version}</version>
               <executions>
                   <execution>
                       <id>attach-sources</id>
                       <goals>
                           <goal>jar</goal>
                       </goals>
                   </execution>
               </executions>
           </plugin>
           <plugin>
               <groupId>org.apache.maven.plugins</groupId>
               <artifactId>maven-javadoc-plugin</artifactId>
               <version>${javadoc.plugin.version}</version>
               <executions>
                   <execution>
                       <id>attach-javadocs</id>
                       <goals>
                           <goal>jar</goal>
                       </goals>
                   </execution>
               </executions>
           </plugin>
       </plugins>
   </build>
</project>

Cycle de vie Maven

Maven a un cycle de vie maven. Il vaut la peine de dire qu'il s'agit d'un ensemble de tâches qu'un maven peut effectuer. Il peut y avoir d'autres tâches en plus du cycle de vie de Maven. De quoi s'agit-il? Il existe un ensemble de commandes avec lesquelles vous pouvez assembler un projet ( build ... encore une fois, bien sûr, un papier calque en anglais, mais sans cela, il n'y a nulle part), supprimer les builds que Maven a collectés, les installer dans Maven local pour que vous puissiez extrayez localement le projet en tant que dépendance, et ainsi de suite. Parlons maintenant de tout plus en détail. Avant d'écrire mon avis sur ces équipes, j'ai décidé de lire ce qu'elles écrivaient sur Internet à ce sujet... et j'ai réalisé que c'était très difficile à décrire. Pour le travail, pour le travail initial, nous avons besoin de plusieurs commandes . Décrivons-les :

• • compiler — compile le projet. C'est la première étape : au cours de celle-ci, vous pouvez voir s'il y a des erreurs de compilation dans le projet. Parfois, il y a plusieurs sauts dans le travail dans IDEA, c'est pourquoi des problèmes de compilation apparaissent là où ils ne devraient pas exister. Cette commande mettra donc les points sur tous les i.
• • test - exécute tous les tests exécutés sur JUnit et situés là où Maven les attend ( src/test/java est votre capitaine).
• • package est la commande suivante, qui inclut les deux précédentes : c'est-à-dire que la commande compile est d'abord lancée à l'intérieur, puis la commande test est envoyée au projet compilé , et si tout va bien ici, la création d'une archive commence (l'archive que nous sélectionnons dans < packaging/>))
• • installer - lorsque nous installons Maven sur une machine, nous disposons d'un référentiel Git local qui stocke les bibliothèques que nous téléchargeons pour les projets. Mais la beauté de Maven est que nous pouvons utiliser la commande install pour ajouter notre projet au référentiel Git local et utiliser notre projet localement comme dépendance. Vous ne me croyez pas ? Essayez-le :) De cette façon, vous pourrez rapidement voir à quoi ressemblera votre projet en tant que dépendance d'un autre.
• • Le déploiement est le couronnement de tout ce qui a précédé. Une commande qui donne la possibilité d'ajouter un projet non seulement à un référentiel local lors de l'installation, mais également à un référentiel distant, à partir duquel toute personne ayant accès peut l'utiliser comme dépendance.
• • verify - une commande qui vérifiera tout et indiquera si le projet est prêt à être déployé.
• • propre - bien entendu, les fichiers compilés et les archives doivent être stockés quelque part. Maven a un dossier cible pour cela . Ce sont des données dont le projet n’a pas besoin. Et avant de remonter le projet, il serait bien de supprimer tout ce qui a précédé. C'est à cela que sert la commande clean .

Plugins Maven

Je voulais parler davantage des plugins, mais l'article est déjà long. Ce seront vos devoirs. Comprenez ce que c'est et comment l'utiliser. Dans la suite de l'article, nous traiterons de Maven en pratique.

Une liste de tous les matériaux de la série se trouve au début de cet article.