pom.xml et settings.xml
Pom.xml et Setting.xml peuvent être considérés comme les deux fichiers de configuration les plus importants de Maven, qui détermine les fonctions principales de Maven. Bien que les articles précédents aient mentionné le contenu dans pom.xml et settings.xml en fragments, ils sont tous brièvement mentionnés et l'apprentissage et la recherche ne sont pas détaillés. Le but de cet article est d'étudier ces deux fichiers de configuration importants en détail. Ces deux fichiers de configuration peuvent conduire à de nombreux sujets Maven.
Coordonnées Maven
Tout d'abord, expliquons pourquoi nous devons utiliser des coordonnées Maven.
Le monde Maven a un très grand nombre de composants, c'est-à-dire certains pots, guerre et autres fichiers qui sont généralement utilisés. Avant que Maven n'introduit le concept de coordonnées pour ces composants, nous ne pouvons utiliser aucune méthode pour identifier de manière unique tous ces composants. Par conséquent, si vous avez besoin d'utiliser les dépendances de printemps, allez sur le site officiel du printemps pour rechercher; Si vous avez besoin d'utiliser les dépendances log4j, accédez au site officiel d'Apache pour rechercher. En raison des différents styles de chaque site Web, beaucoup de temps est consacré à la recherche et à la navigation sur des pages Web. Sans normes et règles unifiées, les travaux ne peuvent pas être automatisés et le travail répétitif doit être laissé aux machines.
Maven définit un ensemble de règles: Tout composant du monde peut être identifié de manière unique par les coordonnées de Maven. Les éléments de coordonnées Maven incluent GroupID, Artifactid, Version, Packaging et Classifier. Maintenant que nous fournissons les coordonnées d'élément correctes, Maven peut trouver le composant correspondant. Quant à savoir où télécharger, Maven lui-même a une adresse intégrée d'un entrepôt central "http://repo1.maven.org/maven2". L'entrepôt central contient la plupart des composants populaires du projet open source au monde. Mavne les téléchargera en cas de besoin. Bien sûr, vous pouvez également configurer votre propre adresse d'entrepôt central et télécharger des composants dans votre propre entrepôt central.
Par exemple, le contexte de Spring:
<dependency> <proupId> org.springframework </rompupid> <letelactid> printemps-context </ artifactid> <version> 4.2.6.release </preinte> </ dépendance
Jetez un œil aux éléments du subordonné:
Il s'agit à peu près du concept de coordonnées Maven. Comprendre les coordonnées de Maven est une étape très importante pour comprendre Maven.
Dépendance transitive
Qu'est-ce que la dépendance transitive? Prenez le printemps comme exemple. Lorsque vous utilisez Spring, vous comptez sur d'autres bibliothèques de classe open source. Il y a deux façons de le faire:
1. Téléchargez un grand package .zip qui contient tous les pots de printemps, mais cela introduit souvent de nombreuses dépendances inutiles
2. Télécharger uniquement les packages .zip liés au printemps, n'incluez pas les dépendances. Lorsque vous les utilisez, ajoutez d'autres dépendances requises en fonction des informations d'erreur.
De toute évidence, les deux approches sont très gênantes, et le mécanisme de dépendance transitif de Maven résout bien ce problème. Ouvrez le pom.xml de Spring-Core-4.1.0.release, et j'intercepte une partie clé:
<Dependances> <Dedency> <GroupId> Commons-codec </rompuprid> <lefactive> Commons-codec </ artifactid> <version> 1.9 </ version> <ccope> compiler </cope> <ochotional> true </acultational> </sendency> <pedigency> <proupId> marchands-ligging </proupId> <Artifactid> Commons-Logging </ artifact> <version> 1.1.3 </ version> <ccope> Compiler </ccope> </dependency> ... </Dependances>
Par exemple, le projet A dépend du printemps-core, le printemps-core dépend du codec de communes et des communes-loging, donc les communes-codec et les communes-loging sont des dépendances transitives du projet A. Avec le mécanisme de dépendance transitif, lorsque vous utilisez le noyau printanier, vous n'avez pas à considérer ce qu'il dépend, et vous n'avez pas à vous soucier de l'introduction de dépendances non inutile. Maven analysera chaque POM de dépendance directe et introduira les dépendances indirectes nécessaires dans le projet actuel sous forme de dépendances transitives.
Avec le mécanisme de dépendance transitive, d'une part, il simplifie et facilite considérablement la déclaration de dépendance. D'un autre côté, dans la plupart des cas, nous n'avons qu'à nous soucier des dépendances directes du projet et n'ont pas besoin de considérer les dépendances transitives qui seront introduites par ces dépendances directes. Cependant, parfois les dépendances transitives auront également quelques problèmes. À l'heure actuelle, nous devons effacer le chemin à partir de laquelle la dépendance transitive a été introduite. C'est ce qu'on appelle la médiation de dépendance. Il y a deux principes principaux de médiation de dépendance:
1. A-> b-> c-> x (1.0), a-> d-> x (2.0), à ce moment, il existe deux versions de x sur les deux chemins de dépendance. À l'heure actuelle, le chemin le plus proche est préféré, donc x (2.0) sera analysé et utilisé.
2. Les longueurs de dépendance de a-> b-> y (1.0), a-> c-> y (2.0), y (1.0) et y (2.0) sont les mêmes. À partir de Maven2.0.9, la première instruction suit la priorité, c'est-à-dire que la dépendance avec l'ordre le plus élevé est préférée.
Exclure les dépendances
Les dépendances transitives introduiront implicitement de nombreuses dépendances au projet, ce qui simplifie considérablement la gestion des dépendances du projet, mais parfois cette fonctionnalité peut également causer des problèmes. Par exemple, il y a une situation:
Le projet actuel dépend de A. A dépend de la version instantanée d'une autre bibliothèque de classe pour une raison quelconque. Ensuite, cet instantané deviendra une dépendance transitive du projet actuel. Deuxièmement, l'instabilité de l'instantané affectera directement le projet actuel. À l'heure actuelle, l'instantané doit être exclu et une version de version formelle de la bibliothèque de classe est déclarée dans le projet actuel.
Il est très simple d'exclure les dépendances, jetons un coup d'œil à la méthode d'écriture:
<dependency> <proupId> com.alibaba.rocketmq </prôdId> <ArtifactId> ROCKETMQ-CLIENT </ Artifactid> <DERVIRED> 3.2.7 </ Version> <cuslisions> <cuslusion> <proupId> Apache-Lang </ GroupId> <Ertifactid> Commons-Lang </ Artifactive> </clusion>
Ici, j'ai introduit la dépendance de RocketMQ, mais je ne veux pas compter sur Apache-Lang dans Rocketmq, mais je veux introduire des dépendances par moi-même, alors j'ai exclu Apache-Lang.
Il convient de noter ici que lors de la déclaration de l'exclusion, seuls GroupID et Arfacactid sont nécessaires et que des éléments de version ne sont pas nécessaires. En effet, seuls groupId et Artifactive sont nécessaires pour localiser de manière unique une dépendance dans le graphique de dépendance. En d'autres termes, dans les dépendances analysées en maven, il est impossible d'avoir deux dépendances avec les mêmes groupid et artefactides, mais différentes versions.
settings.xml
Settings.xml est la configuration de base de Maven. Il y a de nombreux éléments, alors jetons un coup d'œil à un par un.
1. Proxy
Le proxy signifie le proxy de Maven. Jetons un coup d'œil à la méthode d'écriture:
<préxies> <protxy> <id> Facultatif </id> <cactive> true </ active> <protocol> http </protocol> <sersername> proxyuser </ username> </ mot de passe> proxypass </pord> <host> proxy.host.net </host> <port> 80 </port> <NONPROXYHOSTTS> LOCAL.NET | SOME.HOST.com </ NONPROXYHOSTS> </ Proxy> </ Proxies>
Le proxy est nécessaire car plusieurs fois, votre entreprise vous oblige à accéder à Internet à l'aide d'un proxy certifié de sécurité en fonction des considérations de sécurité. Dans ce cas, vous devez configurer un proxy HTTP pour Maven pour lui permettre d'accéder normalement au référentiel externe pour télécharger les ressources requises. Plusieurs éléments proxy peuvent être configurés sous des proxys. Si plusieurs éléments proxy sont déclarés, le premier proxy activé prendra effet par défaut. Active est vrai pour activer le proxy, le protocole représente le protocole de proxy utilisé, bien sûr, la chose la plus importante est de spécifier le nom d'hôte (hôte) et le port (port). Si le serveur proxy a besoin d'authentification, configurez le nom d'utilisateur et le mot de passe. L'élément non-ProxyHost indique quels noms d'hôtes ne nécessitent pas de proxy. Vous pouvez utiliser "|" Pour séparer plusieurs noms d'hôtes et soutenir également le joker "*".
2. Référentiel
Le référentiel représente l'entrepôt central de Maven, car bien que les composants de l'entrepôt distant par défaut soient très grands, il y aura toujours des moments où ils ne répondront pas à nos besoins, puis d'autres entrepôts centraux seront utilisés. Jetons un coup d'œil à la méthode d'écriture:
<Depository> <id> public </id> <name> Nexus privé local </name> <url> http://192.168.1.6:8081/nexus/content/groups/public </url> <eleases> <eabled> true </ compatible> </ libelt> </ slicshots> <enabled> false </abled>
Le référentiel multiple peut être déclaré. L'identité doit être unique. Portez une attention particulière que l'ID utilisée par le référentiel central avec lequel Maven se trouve est central. Si d'autres déclarations de référentiel utilisent également cet ID, la configuration du référentiel central sera écrasée. Les versions et les instantanés sont plus importants. Le premier signifie ouvrir la prise en charge de téléchargement de la version de version pour le référentiel, et le second signifie fermer la prise en charge de téléchargement de la version instantanée pour le référentiel. De cette façon, Maven ira au référentiel pour télécharger la version de version du référentiel sans télécharger la version instantanée du référentiel.
3. Serveur
La plupart des entrepôts éloignés sont accessibles sans authentification, mais parfois ils sont pris en compte dans les facteurs de sécurité et doivent fournir des informations d'authentification pour accéder à certains entrepôts distants. Pour les considérations de sécurité, les informations d'authentification sont généralement placées uniquement dans Settings.xml et le serveur est l'élément d'authentification. Jetez un œil à la configuration:
<Server> <Id> Nexus-Reases </id> <nom d'utilisateur> Déploiement </sername> <mot de passe> Déplacement </SOROSD> </server>
La clé ici est l'ID. Cet ID doit être exactement le même que l'ID de l'élément de référentiel qui doit être authentifié. En d'autres termes, l'ID formel relie les informations d'authentification et la configuration du référentiel.
4. Miroir
Si Warehouse X peut fournir tout le contenu stocké dans l'entrepôt Y, alors Warehouse X peut être considéré comme un miroir de l'entrepôt Y. "http://repo1.maven.org/maven2/" en Chine. En raison de facteurs de localisation géographique, le miroir est souvent en mesure de fournir des services plus rapides que l'entrepôt central, c'est pourquoi le miroir est utilisé.
Jetez un œil à la configuration du miroir:
<Mirror> <id> Nexus </id> <name> Internal NEXUS Repository </name> <url> http://192.168.1.6:8081/nexus/content/groups/public </url> <Mirrorof> * </ Mirrorof> </irror>
Dans cet exemple, Mirrorf est *, indiquant que la configuration est un miroir pour tous les référentiels centraux, et toutes les demandes de référentiel central seront transférées au miroir. Les trois autres éléments, le nom et l'URL ne sont pas différents de la configuration de l'entrepôt général, représentant l'identifiant, le nom et l'adresse unique de l'entrepôt de miroir. De même, si l'image nécessite une authentification, l'authentification du référentiel peut également être configurée en fonction de l'ID.
Merci d'avoir lu, j'espère que cela peut vous aider. Merci pour votre soutien à ce site!