这篇文章上次修改于 422 天前,可能其部分内容已经发生变化,如有疑问可询问作者。

pom.xml主要描述了项目的maven坐标,该文件用于管理:源代码、配置文件、开发者的信息和角色、问题追踪系统、组织信息、项目授权、项目的url、项目的依赖关系等等。是项目级别的配置文件。

声明规范

<?xml version="1.0" encoding="UTF-8"?>
<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">
<!-- pom版本标签(必须要的),表示是一个固定的版本,指定了当前pom的版本 -->
    <modelVersion>4.0.0</modelVersion>

modelVersion

<!--    modelVersion 描述这个POM文件是遵从哪个版本的项目描述符-->
<!--    modelVersion:指定了当前POM模型的版本,对于Maven2及Maven 3来说,它只能是4.0.0;-->
<modelVersion>4.0.0</modelVersion>

packaging

<!-- 打包的机制,如pom,jar, maven-plugin, ejb, war, ear, rar, par,默认为jar -->
<packaging>jar</packaging>

pom ---------> 父类型都为pom类型
jar ---------> 内部调用或者是作服务使用,也可以作为启动项目直接部署,例如springBoot
war ---------> 需要部署的tomcat项目
其中jar和pom的都是可以被依赖的,只不过区别在于pom打包效果只有一个pom文件,可以被其他模块使用parent进行依赖,而jar打包的效果是一个jar包,可以被其他模块使用dependecy标签进行依赖,注意打成jar包也会生成pom文件

pom效果

jar效果

name

<!-- 项目的名称,maven生成文档与展示的时候用 -->
<name>blogserver</name>

description

 <!-- 本项目的详细描述 -->
<description>XXXXX</description>

parent
parent指定一个pom文件
parent依赖对应标签项目所对应的jar包依赖,但不引入标签项目的 java文件等

<!--父项目的坐标。如果项目中没有规定某个元素的值,那么父项目中的对应值即为项目的默认值。坐标包括groupID,artifactID和version等。-->
<parent>
     <groupId>org.springframework.boot</groupId>
     <artifactId>spring-boot-starter-parent</artifactId>
     <version>1.5.9.RELEASE</version>
     <!--父项目的pom.xml文件的相对路径。相对路径允许你选择一个不同的路径。默认值是../pom.xml。Maven首先在构建当前项目的地方寻找父项目的pom,其次在文件系统的这个位置(relativePath(相对路径)位置),然后在本地仓库,最后在远程仓库寻找父项目的pom。-->
     <relativePath/> <!-- lookup parent from repository -->
</parent>

使用maven是为了更好的帮项目管理包依赖,maven的核心就是pom.xml。当我们需要引入一个jar包时,在pom文件中加上就可以从仓库中依赖到相应的jar包。
现在有这样一个场景,有两个web项目A、B,一个java项目C,它们都需要用到同一个jar包:common.jar。如果分别在三个项目的pom文件中定义各自对common.jar的依赖,那么当common.jar的版本发生变化时,三个项目的pom文件都要改,项目越多要改的地方就越多,很麻烦。这时候就需要用到parent标签, 我们创建一个parent项目,打包类型为pom(parent项目只能是pom,不包含任何代码),parent项目中不存放任何代码,只是管理多个项目之间公共的依赖。在parent项目的pom文件中定义对common.jar的依赖,ABC三个子项目中只需要定义,parent标签中写上parent项目的pom坐标就可以引用到common.jar了。
注意,ABC三个子项目如果使用parent中定义的类,还是需要添加对parent的依赖

即,各个子项目,需要添加对parent 的依赖

<dependency>Parent</denpendency>

上面的问题解决了,我们在切换一个场景,有一个springmvc.jar,只有AB两个web项目需要,C项目是java项目不需要,那么又要怎么去依赖。如果AB中分别定义对springmvc.jar的依赖,当springmvc.jar版本变化时修改起来又会很麻烦。解决办法是在parent项目的pom文件中使用将springmvc.jar管理起来,如果有哪个子项目要用,那么子项目在自己的pom文件中使用

<dependency>
    <groupId></groupId>
      <artifactId></artifactId>
</dependency>

标签中写上springmvc.jar的坐标,不需要写版本号,可以依赖到这个jar包了。这样springmvc.jar的版本发生变化时只需要修改parent中的版本就可以了。

当前项目或者子项目中需要哪个依赖,只需写对应坐标,不用写版本,版本统一在当前项目或父项目的中管理(也就是说在本项目中引用的依赖也只是声明,本项目要想使用依赖,也需要在中引用,但是可以不写明版本),子项目不需要该依赖,在子项目的pom中不写依赖的坐标即可
最开始,知道dependencyManagement是管理jar包版本的,如果在父项目中的该节点下声明了包的版本,子项目中在Dependencies中引用该包时就不需要声明版本了,这样保证多个子项目能够使用相同的包版本。
dependencyManagement不实际下载jar包,只会声明包的版本。如果Dependencies中声明了包的版本,则会覆盖dependencyManagement声明的版本。

类似的还有

后续子项目如果不想使用父项目定义的版本,需要通过exclusion排除
使用parent将某项目作为当前项目的父项目后,子项目将继承父项目的

groupId
version
description
url
inceptionYear
organization
licenses
developers
contributors
mailingLists
scm
issueManagement
ciManagement
properties
dependencyManagement
dependencies
repositories
pluginRepositories
build
plugin executions with matching ids
plugin configuration
etc.
reporting
profiles
distributionManagement

properties(配置全局属性)
可被子pom继承

<properties>
    <!-- 项目编码 -->
    <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
    <project.reporting.outputEncoding>UTF-8</project.reporting.outputEncoding>
     <!--在标签内可以把版本号作为变量/属性进行定义(版本锁定),后面dependency中用到版本号时可以用${变量名}的形式代替,这样做的好处是—当版本号发生改变时,只要更新properties标签中的变量值就行了,不用更新所有依赖的版本号-->
    <!-- java版本(但要是做整合的话,那么就不能使用版本绑定了,得要老老实实手动加版本,eg:mybatis整合到spring
        <dependency>
            <groupId>org.mybatis</groupId>
            <artifactId>mybatis-spring</artifactId> 
            <version>2.0.6</version>
        </dependency>-->
    <java.version>1.8</java.version>
    <spring.version>5.0.2.RELEASE</spring.version> <!--RELEASE表示最新的发布版本-->
</properties>

例如

    <dependency>
        <groupId>org.springframework</groupId>
        <artifactId>spring-web</artifactId>
        <!--直接对版本进行引用-->
        <version>${spring.version}</version> 
    </dependency>

dependencies
用于依赖jar包或者war包
type----------依赖的类型,jar或者war(默认为jar,表示依赖的是一个jar包),另外当type表示为pom.lastUpdated 这种属性时,表示只将jar的描述信息加载了进来,实际的jar包并未导入。

<!--本项目的所有依赖关系 --> 
<dependencies>
    <!-- 每个dependency都对应这一个jar包 -->  
    <dependency>
        <!--依赖的坐标--> 
        <groupId>org.mybatis.spring.boot</groupId>
        <artifactId>mybatis-spring-boot-starter</artifactId>
        <version>1.3.1</version>
    </dependency>
    

    <dependency>
        <groupId>com.alibaba</groupId>
        <artifactId>druid</artifactId>
        <version>1.0.29</version>
    </dependency>
    
    <!--junit(单元测试)-->
    <dependency>
        <groupId>junit</groupId>
        <artifactId>junit</artifactId>
        <version>4.12</version>
        <scope>test</scope>
    </dependency>

</dependencies>


依赖坐标 是经典得G.A.V
groupld

<!-- 公司或者组织的唯一标志,并且配置时生成的路径也是由此生成, 如org.sang,maven会将该项目打成的jar包放本地路径:/org/sang --> 
<groupId>org.sang</groupId>

artifactId

 <!-- 本项目唯一的id,一个groupId下面可以有很多个项目,就是靠artifactId来区分的 -->
<artifactId>blogserver</artifactId>

version

<!-- 本项目目前所处的版本号 -->
<version>0.0.1-SNAPSHOT</version>

scope
scope主要是为了管理依赖的部署,确定依赖的使用范围。使用scope标签,可以很方便、直观的进行依赖的总体管理。
scope一共有compile,runtime,test,system,provided 5种属性值,compile为其默认值,其中:
compile表示在所有范围此jar都生效,
test表示只在测试范围此jar生效,例如Junit(默认compile,不会报错,扩展了test),
runtime表示在测试和运行时此jar生效,例如JDBC驱动(默认compile,不会报错,扩展了runtime),我们在编译时是没有用到这个包的,只在测试和运行时会使用到,
provided表示在编译和测试时此jar生效,例如servlet-api,jsp-api,这个的provided必须填写,不能使用compile,原因是:
我们在eclispe里创建web项目时,eclipse为我们添加了这两个jar包,离开了eclispe之后,到Tomcat中Tomcat又会为我们提供这两个包,所以一直不会报错,但是在我们创建maven项目时,我们就不是web项目了,所以eclispe不会为我们添加这两个jar包,就需要我们通过maven来添加,但是如果设置了compile,在Tomcat中运行时,就会与Tomcat中提供的这两个包产生冲突,所以要设置为provided,
这里解释一下编译和打包的含义,编译针对的是我们项目写的java源码,显然不包括依赖的jar,编译完毕之后java源码就变成了可以被执行class字节码,而打包的含义是,将字节码打包成一个可执行的jar包

如果java源码显式的使用了依赖jar包中的类,那么就要求依赖的jar包在编译阶段一定要生效。否则会报错,编译失败。
也有的jar包可能没有没直接被当前项目的java源码显示使用,但是运行时会被会使用,比如被项目的依赖的某个模块进行依赖并且需要调用,那么这种错误是无法在编译阶段发现的。到运行阶段才会发现,那么对于这种jar包需要保证运行阶段有效。
还有就是Junit,和tomcact,servlet-api这种情况,只在本地项目编译运行时需要,打包上正式就不再被需要了,因此可以在打包时忽略
exclusions—排除传递依赖,解决jar冲突问题,
当程序运行起来后jvm在加载类时不会管某个类是那个jar包那个版本的,而是通过类的路径进行加载,因此因为版本冲突,可能会加载不到某个类或者类的方法缺失
依赖传递的意思是项目A依赖项目B,项目B依赖项目C,在使用项目A时,就会加载项目B,这样传递依赖就会把项目C,D,E等等加载进来。其中B是A的直接依赖,C是A的间接依赖
例如:A项目依赖B(版本为1.1),C项目也依赖B(版本为1.2),假如现在有一个项目同时依赖项目A和项目B,那么他就会导入两个版本的B,由于B的两个版本不同,这里就会导致冲突,这个时候就需要exclusions来解决冲突,不过maven也有一个机制会避免两个都加载进去,
下面先介绍maven的依赖调节原则:
1,第一原则:路径近者优先原则
A→B→C→X(1.1)
D→E→X(1.2)
使用X(1.2),因为其路径更近
2,第二原则:第一声明者优先原则
A→B→X(1.1)
C→D→X(1.2)
使用X(1.1),因为其先声明
maven会先根据第一原则判断,若路径相等,再根据第二原则判断

import
在Spring boot 项目的POM文件中,我们可以通过在POM文件中继承 Spring-boot-starter-parent来引用Srping boot默认依赖的jar包,如下:

<!-- Inherit defaults from Spring Boot -->
<parent>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-parent</artifactId>
<version>2.0.1.BUILD-SNAPSHOT</version>
</parent>

但是,通过上面的parent继承的方法,只能继承一个 spring-boot-start-parent。实际开发中,用户很可能需要继承自己公司的标准parent配置,这个时候可以使用 scope=import 来实现多继承。

 <dependencyManagement>
     <dependencies>
         <dependency>
             <!-- Import dependency management from Spring Boot -->
             <groupId>org.springframework.boot</groupId>
             <artifactId>spring-boot-dependencies</artifactId>
             <version>2.0.1.BUILD-SNAPSHOT</version>
             <type>pom</type>
             <scope>import</scope>
        </dependency>
    </dependencies>
</dependencyManagement>

通过上面方式,就可以获取spring-boot-dependencies.2.0.1.BUILD-SNAPSHOT.pom文件中dependencyManagement配置的jar包依赖。
如果要继承多个,可以在dependencyManagement中添加
parent 与 import 的区别
parent会继承父pom的很多个标签
而import只会把dependencyManagement配置全部导入到当前pom中

dependencyManagement
该标签用来在根pom中管理jar包版本,如果后面的jar包没有申明版本,会以这里面的版本为主,使用该标签并不会引入jar包,一般是在父级pom文件申明,方便管理jar包版本

profile
简介
spring boot项目在开发过程中,会涉及到开发、测试、线上的部署,而不同的部署环境需要加载不同的配置文件,此时可以使用profile对打包运行环境进行配置。
使用方式
在pom.xml中配置profile属性,先来看一个完整的配置样例:

<!--分别设置开发,本地,生产环境-->
<profiles>
    <!-- 本地环境 -->
    <profile>
        <!--定义id与maven打包时候的参数对应-->
        <id>local</id>
        <activation>
            <!--默认激活,true:激活,false:不激活-->
            <activeByDefault>true</activeByDefault>
        </activation>
        <!--配置变量,在property或者yml中使用@xxx@进行引用-->
        <properties>
            <!--配置变量名及变量值,变量名可以任意定义-->
            <environment>local</environment>
        </properties>
    </profile>
    <!-- 用户体验环境 -->
    <profile>
        <id>dev</id>
        <activation>
            <activeByDefault>false</activeByDefault>
        </activation>
        <properties>
            <environment>dev</environment>
        </properties>
    </profile>
    <!-- 生产环境 -->
    <profile>
        <id>prod</id>
        <activation>
            <activeByDefault>false</activeByDefault>
        </activation>
        <properties>
            <environment>prod</environment>
        </properties>
    </profile>
</profiles>

可以在profiles里面配置多个profile,每个profile有一个唯一的id值,使用activeByDefault配置默认激活的profile。在maven打包的时候,执行的打包命令:mvn clean package -P dev中的-P后的参数就是指定选中哪个profile,此参数对应于profile中的id值。
配置好profile后,在idea工具中,刷新maven,会出现profile的选项,选择哪一个,idea打包的时候激活的就是对应的配置。

不仅pom中的profile会在这里显示,settings.xml中的profile同样可以在这里切换
activeByDefault
既能用在settings.xml也能用在pom.xml里
配置了标签的profile只会在没有其他激活的profile的情况下被激活
activeProfiles
只能用在settings.xml文件
在里配置的profile会无视其激活条件默认激活,如果指定的profile id不存在则忽略
当我们需要配置一个所有环境都激活的profile,用配置,而需要配置一个其他profile都没有激活

的兜底profile时,用配置
例如:

我们要在settings.xml文件里配置使用阿里云的仓库作为默认仓库,那这个仓库对应的profile就可以用激活
项目的pom.xml通常会配置多个环境,线上prod和线下dev,线下环境的profile就可以用激活,这样编译就可以不用指定-P dev参数而默认就用dev环境
build
在实际使用 Maven 的过程中,会发现 build 标签有时候有,有时候没,这是怎么回事呢?其实通过有效 POM 我们能够看到,build 标签的相关配置其实一直都在,只是在我们需要定制构建过程的时候才会通过配置 build 标签覆盖默认值或补充配置。这一点我们可以通过打印有效 POM 来看到。
完整 build 标签示例在文章末尾,从中能够看到,build 标签的子标签大致包含三个主体部分:

约定的目录结构
默认如不指定,就按照这个相对路径目类进行编译输出

  <sourceDirectory>src/main/java</sourceDirectory>
        <testSourceDirectory>src/test/java</testSourceDirectory>
        <outputDirectory>target/classes</outputDirectory>
        <testOutputDirectory>target/test-classes</testOutputDirectory>
        <resources>
            <resource>
                <directory>src/main/resources</directory>
            </resource>
        </resources>
        <testResources>
            <testResource>
                <directory>src/test/resources</directory>
            </testResource>
        </testResources>
        <directory>target</directory>

能看到各个目录的作用如下:
sourceDirectory 主体源程序存放目录
testSourceDirectory 测试源程序存放目录
outputDirectory 主体源程序编译结果输出目录
testOutputDirectory 测试源程序编译结果输出目录
resources 主体资源文件存放目录
testResources 测试资源文件存放目录
directory 构建结果输出目录
注意这种打包防打出来的包并不是可执行包,一般是用来被依赖的,并不是全量包

plugins
plugins 标签存放的是默认生命周期中实际会用到的插件,这些插件应该都不陌生,所以抛开插件本身不谈,来看看 plugin 标签的结构:

<plugin>
    <artifactId>maven-compiler-plugin</artifactId>
    <version>3.1</version>
    <executions>
        <execution>
            <id>default-compile</id>
            <phase>compile</phase>
            <goals>
                <goal>compile</goal>
            </goals>
        </execution>
        <execution>
            <id>default-testCompile</id>
            <phase>test-compile</phase>
            <goals>
                <goal>testCompile</goal>
            </goals>
        </execution>
    </executions>
</plugin>

坐标部分
artifactId 和 version 标签定义了插件的坐标,作为 Maven 的自带插件这里省略了 groupId

执行部分
executions 标签内可以配置多个 execution 标签,execution 标签内:

id:指定唯一标识
phase:关联的生命周期阶段
goals/goal:关联指定生命周期的目标
goals 标签中可以配置多个 goal 标签,表示一个生命周期环节可以对应当前插件的多个目标。
phase元素代表的是绑定的生命周期的阶段
goals元素代表插件的目标,插件是前面artifactId中定义好的,goals相当于该插件中的一个功能,该功能将在phase绑定的生命周期阶段执行

<execution>
    <id>default-site</id>
    <phase>site</phase>
    <goals>
        <goal>site</goal>
    </goals>
    <configuration>
        <outputDirectory>D:\idea\maven-test\target\site</outputDirectory>
        <reportPlugins>
            <reportPlugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-project-info-reports-plugin</artifactId>
            </reportPlugin>
        </reportPlugins>
    </configuration>
</execution>

configuration 标签内进行配置时使用的标签是插件本身定义的。
结论:每个插件能够做哪些设置都是各个插件自己规定的。

插件的典型应用
指定jdk版本
提出问题
Maven使用的默认Java编译器版本是Java 1.5。为了使Maven使用Java编译器的较新版本编译Java代码,需要在项目的POM文件(pom.xml)中显式指定Java编译器。
从Java 8 和更早版本开始,有两种方法可以在Maven POM文件中设置Java编译器版本:

通过Maven Java编译器属性。
通过Maven Java编译器插件。
Maven Java编译器属性

<properties>
  <maven.compiler.target>1.8</maven.compiler.target>
  <maven.compiler.source>1.8</maven.compiler.source>
</properties>

Maven Java编译器插件
第二种比较冗长的方法是通过插件:

<build>
  <plugins>
    <plugin>
      <groupId>org.apache.maven.plugins</groupId>
      <artifactId>maven-compiler-plugin</artifactId>
      <version>3.6.1</version>
      <configuration>
        <source>1.8</source>
        <target>1.8</target>
      </configuration>
    </plugin>
  </plugins>
</build>

补充说明
configuration标签中source 标签含义
调用 Java 编译器命令时传入的-source参数。那对编译器来说,-source 参数是啥意思呢?

我们写代码是按 JDK 1.8 写的——这就是『源兼容性』里的『源』。
指定发行版就是我们指定的 JDK 1.8。
target 标签含义
整体意思就是源文件编译后,生成的 *.class 字节码文件要符合指定的 JVM 版本
打完整maven的jar包
需求
项目打包,满足以下要求:
1.整个项目打一个Zip包下面包括应用程序、应用程序依赖的jar包、说明文档
2.项目打的jar包可以执行不同类里的Main函数
3.项目源码打的jar包要与依赖的第三方jar包分开
4.项目里的执行脚本也要一块打包并进行分类
5.document目录下的readme.txt放在压缩包的根目录下,其他的还放在这个目录下
6.打的jar包去掉不需要的目录(文件)
Maven使用maven-jar-plugin打可执行jar包

<plugin>
  <groupId>org.apache.maven.plugins</groupId>
  <artifactId>maven-jar-plugin</artifactId>
  <version>2.4</version>
  <!-- 对要打的jar包进行配置 -->
  <configuration>
    <!-- Configuration of the archiver -->
    <archive>
      <!--生成的jar中,不要包含pom.xml和pom.properties这两个文件-->
      <addMavenDescriptor>false</addMavenDescriptor>

      <!-- Manifest specific configuration -->
      <manifest>
        <!--是否要把第三方jar放到manifest的classpath中-->
        <addClasspath>true</addClasspath>
         
        <!--生成的manifest中classpath的前缀,
        因为要把第三方jar放到lib目录下,
        所以classpath的前缀是lib/-->
        <classpathPrefix>lib/</classpathPrefix>
      </manifest>
    </archive>
    <!--过滤掉不希望包含在jar中的文件-->
    <excludes>
      <!-- 排除不需要的文件夹(路径是jar包内部的路径) -->
      <exclude>**/assembly/</exclude>
    </excludes>

  </configuration>
</plugin>

java -classpath dong.jar [main方法所在类] 进行执行

SpringBoot 定制化打包
很显然 spring-boot-maven-plugin 并不是 Maven 自带的插件,而是 SpringBoot 提供的,用来改变 Maven 默认的构建行为。具体来说是改变打包的行为。默认情况下 Maven 调用 maven-jar-plugin 插件的 jar 目标,生成普通的 jar 包。
普通 jar 包没法使用java -jar xxx.jar这样的命令来启动、运行,但是 SpringBoot 的设计理念就是每一个微服务导出为一个 jar 包,这个 jar 包可以使用 java -jar xxx.jar 这样的命令直接启动运行。
这样一来,打包的方式肯定要进行调整。所以 SpringBoot 提供了 spring-boot-maven-plugin 这个插件来定制打包行为。
所有的一切已经都被 SpringBoot 封装好了,所以配置非常简单,提供插件坐标即可。

<!-- build 标签:用来配置对构建过程的定制 -->
<build>
    <!-- plugins 标签:定制化构建过程中所使用到的插件 -->
    <plugins>
        <!-- plugin 标签:一个具体插件 -->
        <plugin>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-maven-plugin</artifactId>
            <version>2.5.5</version>
        </plugin>
    </plugins>
</build>

可以比较 直接默认打包和使用spring-boot-maven-plugin的区别
默认打包不包含被依赖的jar包,也无法执行
使用spring-boot-maven-plugin的包 ,将依赖的全部包都打包到了BOOT-INF的lib下面,能全部执行,并且我们执行java -jar jar包 可直接执行,不再需要手动指定main方法路径

Mybatis逆向工程

 <plugin>
                <groupId>org.mybatis.generator</groupId>
                <artifactId>mybatis-generator-maven-plugin</artifactId>
                <version>1.3.2</version>
                <configuration>
                    <!--配置文件的位置-->
                    <configurationFile>src/main/resources/mybatis-generator/generatorConfig.xml</configurationFile>
                    <verbose>true</verbose>
                    <overwrite>true</overwrite>
                </configuration>
                <dependencies>
                    <dependency>
                        <groupId>org.mybatis.generator</groupId>
                        <artifactId>mybatis-generator-core</artifactId>
                        <version>1.3.2</version>
                    </dependency>
                    <dependency>
                        <groupId>org.postgresql</groupId>
                        <artifactId>postgresql</artifactId>
                        <version>42.2.5</version>
                    </dependency>
                </dependencies>
            </plugin>

引入插件就可以使用生成mapper文件的功能了。

仓库与镜像
本地仓库(localRepositories) > pom.xml文件中的repositories仓库 > setting.xml配置文件中仓库
如果仓库X可以提供仓库Y所有的内容,那么我们就可以认为X是Y的一个镜像,通俗点说,可以从Y获取的构件都可以从他的镜像中进行获取。可以采用镜像的方式配置远程仓库,镜像在settings.xml中进行配置,在setting.xml中的标签下加入如下子标签配置便配置了一个maven镜像。

<mirror>

  <id>alimaven</id>

  <name>aliyun maven</name>


  <mirrorOf>central</mirrorOf>

  <url>http://maven.aliyun.com/nexus/content/groups/public/</url>

</mirror>

mirrorIOf,代表该镜像是那个仓库的镜像,对应仓库的下载地址会被替换为此镜像的地址
添加如上配置后,maven会读取setting.xml中配置的mirror作为jar包的下载地址,

可以看到,配置了上面的mirror后,maven是从aliyun仓库下载的jar包,不配置的时候,默认从apache的maven中央仓库下载的jar包。

上面提到,的设置很重要,比如上面我设置的mirrorOf为central,如果我随便设置一个参数,如abc,这时候我们配置的仓库就不起作用了,这是因为maven默认内置了如下一个仓库,这个默认仓库的id为central,当我们把mirrorOf设置为central时,maven就会查找有没有id为central的仓库,然后把id为central的仓库地址换成我们标签配置的那个url,这样我们配置的mirror才会起作用。当然我们也可以把mirrorOf设置为*,表示所有仓库都使用我们配置的这个mirror作为jar包下载地址。
总结:镜像是说白了提供包含指定仓库的所有资源,会替换掉原先仓库的url使用镜像的url进行资源下载

通过配置
通过setting.xml方式配置会对所有maven项目生效,如果只想在本项目中配置一个maven仓库,可以通过在pom.xml中配置标签来实现。在自己的maven项目的pom.xml中添加如下配置,就配置好了一个仓库。这时候,maven会优先采用这个配置,而不会去读setting.xml中的配置了。这样配置好后,maven就会自动从aliyun下载jar包了。
在pom中配置的仓库如果和setting.xml配置id相同,会采用pom中的配置

<repositories>

  <repository>

    <id>aliyun-releases</id>
    
    <name>阿里云仓库(name可以随便起)</name>
    
    <url>https://maven.aliyun.com/repository/public</url>

  </repository>

</repositories>

我们知道,repositories标签下可以配置多个repository,如果我们配置了多个repository,maven会用哪个呢,答案是按出现顺序使用,如果第1个可用,就用第一个,如果不可用,就依次往下找。
id是配合上面讲的mirror一块使用的,还记得mirrorOf吗,我们配置mirrorOf为central是,mirror中的url就是central仓库的url给覆盖了,所以这里的标签下的id是给mirrorOf用的。

maven仓库配置的其他选项

<!--releases和snapshots中有个enabled属性,是个boolean值,默认为true,

表示是否需要从这个远程仓库中下载稳定版本或者快照版本的构建,

一般使用第三方的仓库,都是下载稳定版本的构建。-->

<repository>

  <id>aliyun-releases</id>

  <url>https://maven.aliyun.com/repository/public</url>

  <releases>

    <enabled>true</enabled>
      <updatePolicy>always</updatePolicy>

  </releases>

  <snapshots>

    <enabled>false</enabled>

  </snapshots>

</repository>

如果snapshots的enable设置为false,那么将无法从仓库拉取-SNAPSHOT的快照包

频率共有四种,分别是always、daily、interval、never。当本地仓库中存在需要的依赖项目时,always是每次都去远程仓库查看是否有更新,daily是只在第一次的时候查看是否有更新,当天的其它时候则不会查看;interval允许设置一个分钟为单位的间隔时间,在这个间隔时间内只会去远程仓库中查找一次,never是不会去远程仓库中查找(这种就和正式版本的行为一样了)。

deploy配置
deploy需要使用maven自带的插件Maven deploy plugin

Maven deploy plugin使用
简介
maven deploy plugin主要是为了用来将artifact部署到远程仓库中。
在setting.xml文件中配置(如果远程仓库没有验证可以忽略)

<server>
  <id>internal.repo</id>
  <username>maven</username>
  <password>foobar</password>
</server>

在pom中配置元素,其中id和server对应的id相同。因为一般是将snapshot的库分开,所以要定义一个元素来存放

<distributionManagement>
    <repository>
      <id>internal.repo</id>
      <name>MyCo Internal Repository</name>
      <url>Host to Company Repository</url>
    </repository>
    <snapshotRepository>
        <id>snapshots</id>
        <name>libs-snapshots</name>
        <url>Host to Snapshot</url>
    </snapshotRepository>
</distributionManagement>