Analyse du fichier pom.xml

1. Présentation de pom :

        L'orthographe anglaise de pom est Project Object Model , le modèle d'objet du projet. Le fichier pom.xml est enregistré au format XML Extensible Markup Language , qui est plus puissant. Ce fichier peut être utilisé pour gérer : le code source, les fichiers de configuration, les informations et les rôles du développeur, le système de suivi des problèmes, les informations organisationnelles, l'autorisation du projet, les URL du projet , les dépendances du projet, etc.

Un fichier pom.xml         complet , placé dans le répertoire racine du projet , contient le contenu spécifique comme suit :

<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
                      http://maven.apache.org/maven-v4_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>

2. Réglage des informations de base :

1. Informations sur la balise d'en-tête :

Collant et prêt à l'emploi, vous pouvez vous référer à cet article de blog "Xmlns, xmlns:xsi et xsi:schemaLocation compréhension dans les documents XML"         pour une description détaillée de ces trois balises

<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
    http://maven.apache.org/xsd/maven-4.0.0.xsd">
</project>

nom de l'étiquette	explication de l'étiquette
xmlns	Espace de noms, similaire au nom du package, car les balises XML peuvent être personnalisées et nécessitent un espace de noms pour être localisées
xmlns:xsi	La spécification de balise que xml doit suivre
xsi:schemaLocation	Il est utilisé pour définir l'adresse de xml schemaLocation , qui est la syntaxe à suivre lors de l'écriture de xml

2. Informations de base sur maven

        Parmi eux,  les quatre éléments groupId , artefactId , version et packaging constituent les coordonnées uniques du projet.En général, les trois premiers éléments suffisent.

<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 
	http://maven.apache.org/xsd/maven-4.0.0.xsd">
	
  	<modelVersion>4.0.0</modelVersion>
  	<groupId>com</groupId>
  	<artifactId>SpringBoot</artifactId>
  	<version>0.0.1-SNAPSHOT</version>
  	<packaging>jar</packaging>
    <name>myName</name>
    <url>www.funtl.com</url>
</project>

nom de l'étiquette	explication de l'étiquette
modèleVersion	Déclare la version du modèle POM suivie par la description du projet. La version du modèle lui-même change rarement, mais il est toujours essentiel d' assurer la stabilité lorsque Maven introduit de nouvelles fonctionnalités ou d'autres modifications du modèle.
identifiant de groupe	L'identifiant unique de l'entreprise ou de l'organisation, et le chemin qui prend effet lors de la configuration sont également générés à partir de celui-ci, comme  com.winner.trade , maven placera le package jar du projet dans le chemin local : /com/winner/ commerce .
ID d'artefact	L' identifiant unique de ce projet , il peut y avoir plusieurs projets sous un groupId , qui se distinguent  par l'artefactld .
version	Le numéro de version actuel de ce projet
emballage	Type d'emballage, valeurs possibles : pom , jar , war , ejb , par , rar , ear , maven-plugin
nom	Le nom du projet, qui est requis pour les documents générés par maven , peut être omis
URL	L'url de la page d'accueil du projet est obligatoire pour les documents générés par maven et peut être omise

3. La relation entre les POM :

        Il est principalement utilisé pour la relation de réutilisation et la relation de dépendance entre les fichiers pom .

3.1. Dépendances - liste des dépendances

        Cet élément décrit toutes les dépendances liées au projet. Ces dépendances forment un maillon dans le processus de construction du projet. Ils sont téléchargés automatiquement depuis le référentiel défini par le projet.

 <dependencies>
    <dependency>
      <groupId>junit</groupId>
      <artifactId>junit</artifactId>
      <version>4.0</version>
      <scope>test</scope>
      <optional>true</optional>
      <exclusions>
      	<exclusion>  
          <groupId>xxx</groupId>
          <artifactId>xxx</artifactId>
        </exclusion>
      </exclusions>
    </dependency>
    …
  </dependencies>

nom de l'étiquette	explication de l'étiquette
identifiant de groupe	Le nom de l'organisation de la dépendance
ID d'artefact	Le nom du sous-projet de la dépendance
version	version des dépendances
taper	Le type de dépendance est généralement omis, le type par défaut est jar , les autres incluent jar , war , ejb-client et test-jar
portée	Champ d'application des dépendances, y compris compile , provide , runtime , test , system et exclusions
facultatif	Dépendances facultatives, si vous déclarez des dépendances C comme facultatives dans le projet B , vous devez référencer explicitement les dépendances sur C dans les projets qui dépendent de B ( tels que le projet A ) .
exclusions	Utilisé lors de l'exclusion des conflits de dépendance dans un projet, ne dépend pas de ce projet

3.1.1. Le champ d'application des dépendances de champ d'application :

       1. compile : la valeur par défaut, applicable à toutes les étapes, et sera publiée avec le projet.

        2. Fourni : Semblable à compile , on s'attend à ce que JDK , conteneur ou utilisateur fournisse cette dépendance, telle que : servlet.jar .

        3. runtime : utilisé uniquement lors de l'exécution , tel que le pilote JDBC , ne sera pas publié avec le projet.

        4. system : Semblable à fourni , il doit afficher le jar contenant les dépendances , et Maven ne le cherchera pas dans le Repository .

        5. optionnel : Lorsque le projet lui-même est dépendant, indiquez si la dépendance est transitive, et elle est utilisée pour la dépendance continue.

        Nous savons tous que les dépendances de maven sont transitives. Tels que : A -> B , B -> C . Mais parfois, le projet A ne dépend pas nécessairement de C , il est donc nécessaire d' exclure la dépendance à C dans le projet A. Dans la gestion des dépendances de maven , il existe deux façons de gérer les dépendances. Il s'agit de dépendances facultatives ( Optional Dependencies ) et d'exclusions de dépendances ( Dependency Exclusions ).

3.1.2, dépendances facultatives

        Lorsqu'un projet A dépend d'un autre projet B , le projet A peut utiliser une petite partie des fonctions du projet B. A ce stade, des dépendances facultatives sur B peuvent être configurées dans A. Par exemple, le projet B est similaire à hibernate , qui prend en charge diverses bases de données telles que mysql et oracle . Mais en citant ce projet, nous ne pouvons utiliser que son support pour mysql .Pour le moment, nous pouvons configurer des dépendances facultatives sur le projet B dans le projet A.

        Raisons de configurer des dépendances facultatives : 1. Économiser du disque, de la mémoire et d'autres espaces ; 2. Éviter les problèmes de licence ; 3. Éviter les problèmes de chemin de classe, etc.

        L'exemple de code est le suivant :

<project>
  ...
  <dependencies>
    <!-- declare the dependency to be set as optional -->
    <dependency>
      <groupId>sample.ProjectB</groupId>
      <artifactId>Project-B</artifactId>
      <version>1.0</version>
      <scope>compile</scope>
      <optional>true</optional> <!-- value will be true or false only -->
    </dependency>
  </dependencies>
</project>

        Supposons que la configuration ci-dessus est la configuration du projet A , c'est-à-dire que le projet A dépend du projet B. Lors de la compilation du projet A , cela peut se passer normalement. S'il existe un nouveau projet C qui dépend du projet A , c'est-à-dire que C dépend de A et A dépend de B , alors le projet C ne dépendra pas du projet B. Si le projet C utilise des fonctions impliquant le projet B , alors la dépendance au projet B doit être reconfigurée dans pom.xml .

3.1.3 Exclusion de dépendance

Cas 1:

        Lorsqu'un projet A dépend du projet B , et que le projet B dépend également du projet C , si le projet A ne souhaite pas référencer le projet C pour diverses raisons , lors de la configuration des dépendances du projet B , la dépendance à C peut être exclue.

Supposons que le pom.xml du projet A         est configuré et que les dépendances sont : A dépend de B et B dépend de C. L'exemple de code est le suivant :

<project>
  ...
  <dependencies>
    <dependency>
      <groupId>sample.ProjectB</groupId>
      <artifactId>Project-B</artifactId>
      <version>1.0</version>
      <scope>compile</scope>
      <exclusions>
        <exclusion>  <!-- declare the exclusion here -->
          <groupId>sample.ProjectC</groupId>
          <artifactId>Project-C</artifactId>
        </exclusion>
      </exclusions> 
    </dependency>
  </dependencies>
</project>

        Bien sûr, pour les dépendances multiples, la configuration est également très simple. Reportez-vous à l'exemple suivant, en supposant que A dépend de B , B dépend de D , D dépend de E , E dépend de F , F dépend de C et A a dépendances multiples E.sur la dépendance sur E , nous n'avons qu'à le faire dans la dépendance de la configuration B :

<project>
  <modelVersion>4.0.0</modelVersion>
  <groupId>sample.ProjectA</groupId>
  <artifactId>Project-A</artifactId>
  <version>1.0-SNAPSHOT</version>
  <packaging>jar</packaging>
  ...
  <dependencies>
    <dependency>
      <groupId>sample.ProjectB</groupId>
      <artifactId>Project-B</artifactId>
      <version>1.0-SNAPSHOT</version>
      <exclusions>
        <exclusion>
          <!-- Exclude Project-E from Project-B -->
          <groupId>sample.ProjectE</groupId> 
          <artifactId>Project-E</artifactId>
        </exclusion>
      </exclusions>
    </dependency>
  </dependencies>
</project>

Cas deux :

        Si notre projet a deux dépendances : A & B , et A et B dépendent de C en même temps , mais C n'est pas la même version. Alors que faisons-nous?

        Tout d'abord, nous devons ajouter le plug-in de vérification. Le code est le suivant. Après avoir ajouté le code, exécutez : mvn project-info-reports:dependencies pour afficher le rapport de dépendance.

<reporting>
	<plugins>
		<plugin>
			<groupId>org.apache.maven.plugins</groupId>
			<artifactId>maven-project-info-reports-plugin</artifactId>
		</plugin>
	</plugins>
</reporting>

        Ensuite, nous supprimons les dépendances, le code ressemble à ceci :

<dependency>
      <groupId>org.apache.struts</groupId>
      <artifactId>struts2-core</artifactId>
      <version>${struts.version}</version>
      <exclusions>
          <exclusion>
              <groupId>org.freemarker</groupId>
              <artifactId>freemarker</artifactId>
          </exclusion>
      </exclusions>
</dependency>

3.2. Relation d'héritage - mécanisme d'héritage d'autres configurations pom.xml

        Dans les projets que nous avons agrégés , il existe de nombreuses configurations répétées, avec le même groupId et la même version , et les mêmes dépendances spring-core , spring-beans , spring-context et juit , causant beaucoup de gaspillage et causant des problèmes, alors comment faire Utiliser le mécanisme d'héritage pour configurer uniformément ces informations répétées, de manière à "déclarer à un endroit, utiliser partout" ?

        À ce stade, vous devez créer une structure parent-enfant du pom et déclarer certaines configurations dans le pom parent pour que le pom enfant hérite.

        Le contenu du parent pom.xml ressemble à ceci :

<project>
  [...]
  <dependencies>
    <dependency>
      <groupId>junit</groupId>
      <artifactId>junit</artifactId>
      <version>4.4</version>
      <scope>test</scope>
    </dependency>
  </dependencies>
  [...]
</project>

Le contenu du fichier pom.xml          enfant  est le suivant. Par défaut , le chemin relatif  est  .../pom.xml . Si le chemin est différent, il doit être spécifié manuellement.

[...]
<parent>
  <groupId>com.devzuz.mvnbook.proficio</groupId>
  <artifactId>proficio</artifactId>
  <version>1.0-SNAPSHOT</version>
  <relativePath>../ParentProject/pom.xml</relativePath>   
</parent>
[...]

3.3. Relation d'agrégation - utilisée pour agréger plusieurs projets maven en un seul grand projet

        Nous voulons construire deux projets à la fois, au lieu d'exécuter des commandes mvn dans les deux répertoires de modules séparément - l'agrégation de Maven sert à répondre à cette exigence. Afin de pouvoir construire deux modules account-email et account-persist avec une seule commande , vous devez créer un module supplémentaire nommé account-aggregator , puis construire tous les modules de l'ensemble du projet via ce module.

       Le contenu du pom.xml du projet  account-aggregator est le suivant :

<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
        http://maven.apache.org.maven-v4_0_0.xsd">
    <modelVersion>4.0.0</modelVersion>
    <groupId>com.park.mvnDemo.account</groupId>
    <artifactId>account-aggregator</artifactId>
    <version>1.0.0-SNAPSHOT</version>
    <packaging>pom</packaging>
    <name>Account Aggregator</name>
    <modules>
        <module>account-email</module>
        <module>account-persist<module>
    </modules>
</project>

        Dans le fichier xml ci-dessus , la méthode d'empaquetage est pom . Pour le module d'agrégation, sa méthode d'empaquetage doit être pom , sinon il ne peut pas être construit !

        modules : il s'agit de la configuration de base pour réaliser l'agrégation. Vous pouvez déclarer n'importe quel nombre d' éléments de module pour réaliser l'agrégation d'éléments ; où la valeur de chaque module est le chemin relatif de l'agrégation actuelle pom .

        Par exemple : le pom d'agrégation actuel est situé à D:\m2\code\account-aggregator\ , le projet A est situé à D:\m2\code\account-aggregator\account-email\ et un projet B est situé à D:\m2\code\- aggregatoraccount\account-persist\ , correspondant à la valeur du module dans le pom d'agrégation ci-dessus. Il peut également être écrit sous la forme /account-email.

        Afin de faciliter la création de projets par les utilisateurs, le module d'agrégation est généralement placé en haut du répertoire du projet , et d'autres modules existent en tant que sous-répertoires du module d'agrégation. Bien sûr, vous pouvez également spécifier le chemin manuellement.

4. Les six types d'attributs de Maven :

4.1. Propriétés intégrées de Maven

        Il existe principalement deux propriétés intégrées couramment utilisées, comme suit :

nom de l'étiquette	explication de l'étiquette
${basé}	Le répertoire racine du projet (le répertoire contenant le fichier pom.xml)
${version}	version du projet

4.2, propriétés pom

        Les utilisateurs peuvent utiliser cet attribut pour faire référence à la valeur de l'élément correspondant dans le fichier pom . Les attributs pom couramment utilisés incluent :

nom de l'étiquette	explication de l'étiquette
${project.build.sourceDirectory}	Le répertoire principal du code source du projet, la valeur par défaut est src/main/java
${project.build.testSourceDirectory}	Le répertoire source de test du projet, la valeur par défaut est src/test/java
${project.build.directory}	Répertoire de sortie du composant de projet, la valeur par défaut est target/
${project.outputDirectory}	Répertoire de sortie de la compilation du code principal du projet, la valeur par défaut est target/classes/
${project.testOutputDirectory}	Répertoire de sortie de la compilation du code de test du projet, la valeur par défaut est target/test-classes/
${project.groupId}	Le groupId du projet
${project.artifactId}	ID d'artefact du projet
${project.version}	La version du projet , équivalente à ${version}
${project.build.fianlName}	Le nom du fichier de sortie de l'empaquetage du projet, la valeur par défaut est " ${project.artifactId} - ${project.version} "

4.3. Attributs personnalisés

        Les utilisateurs peuvent personnaliser les propriétés Maven sous l'élément pom , l'exemple de code est le suivant, puis nous pouvons les utiliser via ${zipkin.version} dans le fichier pom .

 <!--配置依赖版本-->
 <properties>
     <!-- Environment Settings -->
     <java.version>1.8</java.version>
     <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
     <project.reporting.outputEncoding>UTF-8</project.reporting.outputEncoding>

     <!-- Spring cloud Settings   -->
     <spring-cloud.version>Finchley.RELEASE</spring-cloud.version>
     <spring-boot-admin.version>2.0.1</spring-boot-admin.version>
     <zipkin.version>2.10.1</zipkin.version>
 </properties>

4.3.1 dependencies 和 dependencyManagement 标签：

        在通常情况下，由于我们的模块很多，我们需要一个 itoken-denpendencies 的项目来管理子项目的公共的依赖。为了项目的正确运行，必须让所有的子项目使用依赖项的统一版本，必须确保应用的各个项目的依赖项和版本一致，才能保证测试的和发布的是相同的结果。

        在我们项目顶层的 pom 文件中，我们会看到 dependencyManagement 元素。通过它元素来管理 jar 包的版本，让子项目中引用一个依赖而不用显示出具体的版本号。结合 maven 的自定义属性，我们来看看项目中的具体应用：

        下面是 itoken-denpendencies 中的 pom.xml ，在父项目中用 dependencyManagement 声明依赖的版本：

<dependencyManagement>
	<dependencies>
	    <!--spring cloud-->
	    <dependency>
	        <groupId>org.springframework.cloud</groupId>
	        <artifactId>spring-cloud-dependencies</artifactId>
	        <version>${spring-cloud.version}</version>
	        <type>pom</type>
	        <scope>import</scope>
	    </dependency>
	    <!--zipkin-->
	    <dependency>
	        <groupId>io.zipkin.java</groupId>
	        <artifactId>zipkin</artifactId>
	        <version>${zipkin.version}</version>
	    </dependency>
	    [...]
	<dependencies>
</dependencyManagement>            

        在子项目中，Maven 会沿着父子层次向上走，直到找到一个拥有 dependencyManagement 元素的项目，然后它就会使用在这个 dependencyManagement 元素中指定的版本号。 itoken-zipkin 中的 pom.xml 内容如下所示：

<dependencies>
    <!--spring cloud-->
    <dependency>
        <groupId>org.springframework.cloud</groupId>
        <artifactId>spring-cloud-dependencies</artifactId>
    </dependency>
    <!--zipkin-->
    <dependency>
        <groupId>io.zipkin.java</groupId>
        <artifactId>zipkin</artifactId>
    </dependency>
    [...]
<dependencies>

        需要注意的是，dependencyManagement 里只是声明依赖，并不实现引入。如果不在子项目中声明依赖，是不会从父项目中继承下来的；只有在子项目中写了该依赖项，并且没有指定具体版本，才会从父项目中继承该项，并且 version 和 scope 都读取自父 pom。如果子项目中指定了版本号，那么会使用子项目中指定的 jar 版本。

4.4、Settings 属性

        用户使用 ${settings.} 开头的属性可以引用 maven settings.xml 文件中 xml 元素的值，如下所示：

标签名称	标签解释
settings.localRepository	自定义本地库路径，默认在 ${user.home}/.m2 中
settings.interactiveMode	交互模式，Maven 是否应该尝试与用户输入交互，默认是 true，如果不是 false。
settings.offline	是否每次编译都去查找远程中心库， 如果此构建系统应以离线模式运行，则为 true，默认为 false。由于网络设置或安全原因，此元素对于构建无法连接到远程存储库的服务器非常有用。
settings.pluginGroups	插件组，例如 org.mortbay.jetty

4.5、Java系统属性

        所有 Java 系统属性都可以使用 Maven 属性引用，这里列举一些常用的 Java 系统属性。

标签名称	标签解释
java.version	Java 运行时环境版本
java.vendor	Java 运行时环境供应商
java.vendor.url	Java 供应商的 URL
java.home	Java 安装目录
java.vm.specification.version	Java 虚拟机规范版本
java.vm.specification.vendor	Java 虚拟机规范供应商
java.vm.specification.name	Java 虚拟机规范名称
java.vm.version	Java 虚拟机实现版本
java.vm.vendor	Java 虚拟机实现供应商
java.vm.name	Java 虚拟机实现名称
java.class.path	Java 类路径
os.name	操作系统的名称
file.separator	文件分隔符（在 UNIX 系统中是“/”）
user.name	用户的账户名称
user.home	用户的主目录
user.dir	用户的当前工作目录

4.6、环境变量属性

        所有环境变量都可以使用以 env. 开头的 Maven 属性引用。比如：${env.JAVA_HOME} 表示环境变量的值。

5、构建设置

        build 标签可以是单独的，也可以是包含在 profile 标签里面，如下所示：

<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
                      http://maven.apache.org/maven-v4_0_0.xsd">
  <!– "Project Build" contains more elements than just the BaseBuild set –>
  <build>…</build>
  <profiles>
    <profile>
      <!– "Profile Build" contains a subset of "Project Build"s elements –>
      <build>…</build>
    </profile>
  </profiles>
</project>

        build 标签包含两个子标签，分别是 Resources 标签和 Plugins 标签，下面分别介绍下这两个标签。

5.1 Resources 标签

        资源文件管理，用于引用或者排除资源文件，如下所示：

<resources>
	<resource>
		<targetPath>META-INF/plexus</targetPath>
		<filtering>false</filtering>
		<directory>${basedir}/src/main/plexus</directory>
		<includes>
		  <include>configuration.xml</include>
		</includes>
		<excludes>
		  <exclude>**/*.properties</exclude>
		</excludes>
	</resource>
</resources>

标签名称	标签解释
targetPath	资源的打包路径，该路径相对 target/classes 目录
filtering	主要用来替换项目中的资源文件（* .xml、* . properties）当中的 $ {…} 属性值如 $ {db.url}  如果 filtering=true 在 resources 目录中存在资源文件并且配置了 db.url=aaa 的话，  在项目编译的时候，就会自动的把 pom 文件中的 ${db.url} 替换为 aaa
directory	描述存放资源的目录，该路径相对 pom 的路径
includes	包含的模式列表，例如 **/*.xml
excludes	排除的模式列表，例如 **/*.xml

5.2 Plugins 标签

        设置构建的插件，为什么我们需要插件？

        第一个原因是我们需要某个特殊的 jar 包，但是又不能直接通过 maven 依赖获取，或者说在其他环境的 maven 仓库内不存在，那么如何将我们所需要的 jar 包打入我们的生产 jar 包中。就需要这个插件。

        第二个原因是某个 jar 包内部包含的文件是我们所需要的，或者是我们希望将它提取出来放入指定的位置 ，那么除了复制粘贴，也可以通过 maven 插件实现。

5.2.1 plugins 和 pluginmanagement 

        maven 通过 plugins 和 pluginmanagement 来管理插件，类似 dependencies 和 dependencyment 。但需要注意的是，plugins 和 pluginmanagement 隶属于 build 标签下，而不是最外层的 project 标签。

        在父项目中声明插件和版本信息，同样 pluginmanagement 也不会直接引入插件。

<pluginManagement>
    <plugins>
        <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-source-plugin</artifactId>
            <version>2.1</version>
            <configuration>
                <attach>true</attach>
            </configuration>
            <executions>
                <execution>
                    <phase>compile</phase>
                    <goals>
                        <goal>jar</goal>
                    </goals>
                </execution>
            </executions>
        </plugin>
    </plugins>
</pluginManagement>

        在子项目中引入插件，同样，子项目继承父项目的 plugin 设置，并可以自由定义。

<plugins>
    <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-source-plugin</artifactId>
    </plugin>
</plugins>

 6、Maven 仓库配置

        Maven 仓库就是放置所有 JAR 文件（WAR，ZIP，POM 等等）的地方，所有 Maven 项目可以从同一个 Maven 仓库中获取自己所需要的依赖 JAR，这节省了磁盘资源。此外，由于 Maven 仓库中所有的 JAR 都有其自己的坐标，该坐标告诉 Maven 它的组件 ID，构件 ID，版本，打包方式等等，因此 Maven 项目可以方便的进行依赖版本管理。你也不再需要提交 JAR 文件到 SCM 仓库中，你可以建立一个组织层次的 Maven 仓库，供所有成员使用。

        简言之，Maven仓库能帮助我们管理构件（主要是JAR）。maven 寻找仓库的顺序大致可以理解为：

                1、在本地仓库中寻找，如果没有则进入下一步。

                2、在全局应用的私服仓库中寻找，如果没有则进入下一步。

                3、在项目自身的私服仓库中寻找，如果没有则进入下一步。

                4、在中央仓库中寻找，如果没有则终止寻找。

补充：

        1、如果在找寻的过程中，如果发现该仓库有镜像设置，则用镜像的地址代替。

        2、如果仓库的 id 设置成 “ central ” ，则该配置会覆盖 maven 默认的中央仓库配置。

6.1 本地仓库：

        Maven 缺省的本地仓库地址为 ${user.home}/.m2/repository 。也就是说，一个用户会对应的拥有一个本地仓库。你也可以自定义本地仓库的位置，修改 ${user.home}/.m2/settings.xml 。

<localRepository>D:/repo</localRepository>

        也可以在运行时指定本地仓库位置： 

mvn clean install -Dmaven.repo.local=/home/juven/myrepo/

6.2 中央仓库：

        3.xxx 版本之后，在 maven 安装目录下的：/lib/maven-model-builder-${version}.jar 中
打开该文件，能找到超级 pom ：\org\apache\maven\model\pom-4.0.0.xml，它是所有 Maven  pom 的父 pom ，所有 Maven 项目继承该配置，你可以在这个 pom 中发现如下配置：

  <repositories>
    <repository>
      <id>central</id>
      <name>Central Repository</name>
      <url>https://repo.maven.apache.org/maven2</url>
      <layout>default</layout>
      <snapshots>
        <enabled>false</enabled>
      </snapshots>
    </repository>
  </repositories>

        中央仓库的 id 为 central，远程 url 地址为 http://repo.maven.apache.org/maven2 ，它关闭了 snapshot 快照版本构件下载的支持。

6.3 在 pom.xml 中配置远程仓库：

        Plus tôt, nous avons vu que le super pom est configuré avec un entrepôt distant avec un ID de central , et nous pouvons configurer d'autres entrepôts distants dans le pom . Il y a plusieurs raisons à cela. Par exemple, si vous avez un entrepôt distant dans le réseau local, l'utilisation de cet entrepôt peut augmenter considérablement la vitesse de téléchargement, puis améliorer la vitesse de construction. Il est également possible qu'un fichier jar dont vous dépendez ne puisse pas être trouvé dans le central, et il n'existe que dans un certain référentiel public spécifique, vous devez donc également ajouter la configuration de ce référentiel distant. Ici, je configure un entrepôt distant pour qu'il pointe vers l'image chinoise de l'entrepôt central :

<project>
...
  <repositories>
    <repository>
      <id>maven-net-cn</id>
      <name>Maven China Mirror</name>
      <url>http://maven.net.cn/content/groups/public/</url>
      <releases>
        <enabled>true</enabled>
      </releases>
      <snapshots>
        <enabled>false</enabled>
      </snapshots>
    </repository>
  </repositories>
  <pluginRepositories>
    <pluginRepository>
      <id>maven-net-cn</id>
      <name>Maven China Mirror</name>
      <url>http://maven.net.cn/content/groups/public/</url>
      <releases>
        <enabled>true</enabled>
      </releases>
      <snapshots>
        <enabled>false</enabled>
      </snapshots>    
    </pluginRepository>
  </pluginRepositories>
...
</project>

        Examinons d'abord sa configuration, vous pouvez en ajouter plusieurs, chacune avec son ID unique, un nom descriptif et, plus important encore, l'URL du référentiel distant . aussi:

<!-- 告诉Maven可以从这个仓库下载releases版本的构件 -->
<releases><enabled>true</enabled></releases>   

<!-- 告诉Maven不要从这个仓库下载snapshot版本的构件。 -->
<snapshots><enabled>false</enabled></snapshots>

        Il est recommandé de désactiver les artefacts d'instantané des référentiels publics, car ces artefacts sont instables et hors de votre contrôle, et vous devez les éviter. Bien entendu, si vous souhaitez utiliser l'entrepôt au sein de l'organisation au sein du réseau local, vous pouvez activer la prise en charge des instantanés.