1.1 Grands programmes
Nous avons déjà appris à écrire de petits programmes, alors maintenant nous allons apprendre à en écrire de grands. Comme vous le savez, plus le programme est grand et complexe, plus l'argent est payé pour son développement :) Et commençons par un peu de contexte ...
À mesure que les programmes grandissent en taille, les développeurs sont confrontés à deux nouveaux défis :
- Un grand nombre de personnes travaillent sur le même programme.
- Il n'y a pas une telle personne qui connaîtrait le code entier du programme.
Très souvent, des situations ont commencé à se produire lorsqu'un programmeur a corrigé un bogue à un endroit du programme et en même temps cassé quelque chose à un autre. La documentation de la version contient même cette blague :
Liste des modifications :
- Correction d'anciens bugs :)
- Ajout de nouveaux :(
Ensuite, ils ont proposé deux approches pour résoudre ce problème : technique et managériale.
L'approche technique était que les programmes étaient divisés en parties : bibliothèques et modules . Chacun de ces modules était une petite brique à partir de laquelle de grands projets étaient ensuite construits. Les bibliothèques sont de tels composants universels qui peuvent être utilisés dans différents programmes.
L'approche managériale était encore plus intéressante - elle limitait le nombre de personnes pouvant travailler sur un projet/une bibliothèque. Empiriquement, ils ont même proposé une règle : l'équipe devait être si nombreuse qu'« elle pourrait être nourrie avec deux pizzas » . Cela signifie généralement que si plus de 8 personnes travaillent sur un projet , celui-ci doit être divisé en deux projets.
Il est devenu populaire dans la communauté des développeurs Java d'écrire des bibliothèques pour toutes les occasions et de les rendre accessibles au public. Ainsi, les programmeurs Java ne pouvaient plus écrire le même code (qui était souvent brut et contenait des bugs), mais utilisaient des solutions toutes faites et éprouvées .
Une incitation supplémentaire était le fait que le langage Java a gagné en popularité lors de l'écriture de solutions côté serveur (il fonctionnait sur le backend). Premièrement, les logiciels serveur ont des exigences plus élevées en matière de fiabilité, et l'utilisation de bibliothèques éprouvées est toujours préférable à l'écriture de votre propre code.
Deuxièmement, les serveurs n'ont pratiquement aucune limite sur la taille du code. Le développeur d'une application mobile essaie de l'entasser dans 10 mégaoctets, une application de bureau - dans 100 mégaoctets. Et un développeur backend Java peut entasser plusieurs dizaines de gigaoctets de bibliothèques dans un projet et personne ne lui dira un mot :)
Soit dit en passant, ce n'est pas une blague. Vous pouvez facilement trouver un projet backend avec plusieurs dizaines de modules et quelques centaines de bibliothèques. Mais il est devenu extrêmement difficile de décrire (et de modifier !) les scripts de build pour de tels projets.
Et puis Maven est apparu.
1.2 Présentation de Maven
Maven est un "framework" spécial pour la gestion de la construction de projets. Il standardise 3 choses :- Description du projet ;
- Scripts de génération de projet ;
- Dépendances entre bibliothèques.
Le prédécesseur de Maven était Ant , et son successeur est Gradle . Mais c'est Maven qui a développé et perfectionné les trois normes répertoriées, et a également réglementé leur interaction. C'est lui qui a amené le travail des communautés Java à un nouveau niveau. Regardons cela plus en détail.
Techniquement, Maven est un programme / service spécial dont le but principal est de gérer le processus de construction de projets. Il peut être simplement téléchargé en tant qu'archive et décompressé dans n'importe quel répertoire. Vous n'avez pas besoin d'un installateur spécial pour cela.
Elle n'a pas d'interface graphique - toutes les commandes lui sont données à l'aide de la console . Pour rendre son utilisation encore plus confortable, il est recommandé d'enregistrer des variables d'environnement spéciales dans votre système d'exploitation.
Maven dispose également d'un référentiel spécial (répertoire/dossier) où il stocke les bibliothèques qu'il utilise lors de la construction de projets. Vous devrez sélectionner un dossier sur le disque et l'affecter en tant que référentiel.
Une autre chose intéressante est la présence d'un référentiel Maven global pour toutes les bibliothèques, mais nous en reparlerons un peu plus tard.
1.3 Télécharger et installer Maven
Maven a un site officiel maven.apache.org . Il y a beaucoup de documentation sur le projet, donc si vous avez des difficultés ou des questions supplémentaires - entrez, ne soyez pas timide.
Également sur la page des téléchargements ( https://maven.apache.org/download.cgi ), vous pouvez télécharger l'archive maven (apache-maven-3.8.5-bin.zip). L'archive décompressée prendra environ 10 Mo, bien que le référentiel maven local nécessitera éventuellement plusieurs centaines de mégaoctets de mémoire.
Maven est écrit en Java et nécessite un JRE d'au moins la version 7, ainsi que des variables d'environnement JAVA_HOME définies.
Créez simplement un dossier pour Maven sur votre ordinateur, par exemple, d:\devtools , et extrayez l'archive avec Maven dedans. En conséquence, vous devriez obtenir un dossier comme d:\devtools\maven\bin , où se trouveront les principaux binaires du projet.
1.4 Variables d'environnement
Après cela, vous devez ajouter le chemin d'accès au dossier bin de l'archive décompressée à la variable d'environnement PATH.
Pour définir la variable d'environnement dans Windows 10, vous devez accéder à Panneau de configuration - Système - Paramètres système avancés. Cliquez ensuite sur "Variables d'environnement", recherchez PATH et sélectionnez "Modifier", puis ajoutez le chemin d:\devtools\maven\bin à la fin de la ligne. Faites attention, le chemin doit mener exactement au dossier bin.
Sur un système d'exploitation basé sur Unix, la variable d'environnement peut être ajoutée avec une commande de console :
export PATH=/opt/apache-maven-3.8.5/bin:$PATHSi vous avez tout fait correctement, dans la console, vous devez taper la commande : "mvn -v". En réponse, vous verrez quelque chose comme :
C:\Users\Zapp>mvn -v
Apache Maven 3.0.5 (r01de14724cdef164cd33c7c8c2fe155faf9602da; 2013-02-19 15:51:28+0200)
Maven home: T:\apache-maven-3.0.5\bin\..
Java version: 1.8.0_65, vendor: Oracle Corporation
Java home: C:\Program Files\Java\jdk1.8.0_65\jre
Default locale: en_US, platform encoding: Cp1251
OS name: "windows 7", version: "6.1", arch: "amd64", family: "dos"1.5 Référentiel Maven local
Vous pouvez également définir un dossier spécial dans lequel Maven stockera les bibliothèques jar qu'il utilisera lors de la création de projets. Ce dossier s'appelle le référentiel maven local .
Si aucun dossier de ce type n'est spécifié, Maven le créera dans le répertoire personnel de l'utilisateur actuel. Mon répertoire est : C:\Users\Zapp\.m2
Le dossier a un nom assez spécifique ".m2". Bien que cela n'effraie pas les utilisateurs de Linux, c'est une approche assez courante pour nommer divers "dépôts" et / ou tout autre stockage d'informations de service.
Important! Ne placez pas Maven dans des dossiers système, car il aura besoin d'autorisations d'écriture sur ces dossiers pendant le fonctionnement, ce qui peut présenter un intérêt malsain pour l'antivirus ou le système d'exploitation.
Maven avant la version 3.5 nécessitait une variable d'environnement appelée M2_HOME, mais ce n'est plus nécessaire.
Vous pouvez en savoir plus sur la configuration de Maven sur le lien : https://maven.apache.org/configure.html