Maven

Maven基础

1.通过修改settings.xml文件，可以为maven添加镜像加速服务，也可以修改默认的本地仓库位置等。
该文件的默认路径为

Maven安装路径\conf\settings.xml

2.当执行Maven命令需要用到某些插件时，Maven会先到本地仓库中查找，如果在本地仓库中找不到，则会联网到中央仓库下载。
本地仓库的默认位置为

[系统中当前用户的家目录]\.m2\repository

// 例如windos下为
C:\Users\wbin3\.m2\repository
// linux下为
/home/wbin3/.m2/repository

3.maven构建的各个环节

• 清理： 将以前编译得到的旧的class字节码文件删除，为下一次编译做准备
• 编译： 将.java文件编译成.class字节码文件
• 测试： 自动测试，自动调用junit程序
• 报告： 测试程序执行的结果
• 打包： 动态Web工程打war包，Java工程打jar包
• 安装： Maven特定的概念，将打包得到的jar文件，复制到“仓库”中的指定位置
• 部署： 将动态Web工程生成的war包复制到Servlet容器的指定目录下，使其可以运行

常用命令

mvn clean:清理
mvn compile: 编译
mvn test-compile: 编译测试程序
mvn test: 执行测试
mvn package:打包
mvn install: 安装
mvn deploy: 自动部署

坐标

• 在Maven中使用以下三个标识，在仓库中唯一定位一个Maven工程

<groupid>: 公司或组织域名倒叙+项目名
<groupid>:com.arcc.maven</groupid>

<artifactid>: 模块名
<artifactid>demo</artifactid>

<version>:版本号
<version>1.0.0</version>

• Maven工程与仓库中路径的对应关系

// 现在有这么一个坐标
<groupid>:com.arcc.maven</groupid>
<artifactid>demo</artifactid>
<version>1.0.0</version>

// 那么它在仓库中的路径为
com/arcc/maven/demo/1.0.0/demo-1.0.0.jar

仓库

• 本地仓库：当前电脑上部署的仓库目录，为当前电脑上所有Maven工程服务

• 远程仓库：
  -- 私服： 搭建在局域网环境中，为局域网范围内的所有Maven工程服务

  
  私服

-- 中央仓库： 架设在Internet上，为全世界所有Maven工程服务
-- 中央仓库的镜像：架设在各大洲，为中央仓库分担流量，减轻中央仓库压力，例如阿里云就提供了Maven的镜像服务。

依赖【初级】

1.Maven解析依赖信息时会先到本地仓库中查找被依赖的jar包,如果本地仓库中找不到，会到中央仓库中查找。
2.对于我们自己开发的Maven工程，使用mvn install命令安装后就可以将该项目打包成Jar包放入本地仓库中
3.Maven在导入依赖的Jar包时，会自动将该Jar包的所需依赖的Jar包一并导入。例如在导入spring-core.Jar时，因为spring-bore.jar依赖于commons-logging.jar，所以maven会将commons-logging.jar包一并导入到项目中

4.依赖的范围：

// 首先看一下下面这段xml
<dependencies>
    <dependency>
        <groupId>junit</groupId>
        <artifactId>junit</artifactId>
        <version>4.0</version>
        <scope>test</scope>
    </dependency>

    <dependency>
        <groupId>com.arcc.maven</groupId>
        <artifactId>Hello</artifactId>
        <version>0.0.1-SNAPSHOT</version>
        <scope>compile</scope>
    </dependency>
</dependencies>

其中<scope>标签标示的就是依赖的范围，主要有compile(编译范围)、test（测试范围）以及provided（生产范围）。

上面这段xml，第一段<dependency>的意思是指，引入junit包，依赖范围为测试范围。意思是，只有当执行mvn test命令时，才会将junit包导入到项目。
而第二段<dependency>的意思是指引入Hello包，依赖范围为编译范围，当执行mvn compile命令时，会导入hello包。

三种依赖范围在执行不同mvn命令时，是否会导入相关范围内依赖的jar包，如下图所示

image.png

这里需要注意，什么情况下会用到provided依赖范围，上图中可以看到，provided依赖范围的jar包不参与到打包，但是将打包好的项目部署到服务器上时，又能正常运行。说明服务器上提供了该jar包，例如tomcat本身提供了servlet-api.jar包，当我们项目中需要用到这些jar包时，便可把他们的依赖范围声明为<scope>provided</scope>。

依赖【高级】

1. 依赖的传递性

可以传递的依赖不必在每个Maven项目中都重复声明，在依赖最底层的工程中声明一次即可。
例如项目A->B(A依赖于B),那么我们只需要在项目B中申明即可。
需要注意的是非compile范围的依赖不能传递。

2.依赖的排除
使用以下标签可以排除指定的Jar包
现在有两个项目A、B,且A->B（A依赖于B）。我们在A项目中添加了下面的标签，那么A项目中会将该jar包排除，但是B项目不会排除该jar包。
那么如果现在有三个项目，A->B->C。我们在B项目中添加了<exclusions>标签，那么A项目中也不会导入该Jar包。

<dependency>
    ...
    <exclusions>
        <exclusion>
            <groupId>commons-logging</groupId>
            <artifactId>commons-logging</artifactId>
        </exclusion>
    </exclusions>
</dependency>

3.依赖的引用优先级

• 路径最短者优先
  下图有三个项目，MakeFriends项目依赖于HelloFriend，HelloFriend依赖于Hello。
  由于项目需要Hello项目导入了log4j.1.2.17.jar,而HelloFriend项目导入了log4j.1.2.14.jar。
  根据依赖的传递性，MakeFriends项目中会同时存在log4j.1.2.14和log4j.1.2.17。
  当出现上述情况，Maven会选择路径最短的Jar包，HelloFriend距离MakeFriends为1，而距离Hello为2，所以Maven会选择log4j.1.2.14作为MakeFriends项目的jar包。

  
  image.png

• 路径相同时，先声明者优先，声明是指<dependency>标签的声明顺序。

image.png

使用<properties>标签定义变量

• 首先使用<properties>标签定义统一声明变量
• 然后在需要使用的位置，使用${自定义标签名}引用申明的变量

用法如下：

<properties>
    <junit.version>1.0.0</junit.version>
</properties>

<dependencies>
    <dependency>
        <groupId>junit</groupId>
        <artifactId>junit<artifactId>
        <version>${junit.version}</version>
    <dependency>
<dependencies>

继承

场景：
现在有三个项目A、B、C，A依赖于B,B依赖于C。
A依赖的junit为4.0
B依赖的junit为4.0
C依赖的junit为4.9
这是由于test范围的依赖不能传递，导致的各个项目中junit版本不一致，会对团队的协同工作带来影响。

解决思路：
将junit依赖版本统一提取到"父”工程中，在子工程中声明依赖时不指定版本，以父工程中统一设定的为准。

步骤：
1.创建一个Maven工程作为父工程。注意：打包方式为pom
2.在子工程中声明对父工程的引用
3.将子工程的坐标中与父工程坐标中重复的内容删除
4.在父工程中统一junit的依赖
5.在在工程中删除Junit依赖的版本号
6.配置继承后，执行安装命令时要先安装父工程

父工程pom.xml

<modelVersion>4.0.0</modelVersion>
<groupId>com.arcc.demo</groupId>
<artifactId>Parent</artifactId>
<version>0.0.1</version>
<packaging>pom</packaging>

// 配置依赖的管理
<dependencyManagement>
    <dependencies>
        <dependency>
            <groupId>junit</groupId>
            <artifactId>junit</artifactId>
            <version>4.0</version>
            <scope>test</scope>
        </dependency>
    </dependencies>
</dependencyManagement>

子工程pom,使用<parent>标签什么对父工程的依赖

<parent>
    <groupId>com.arcc.demo</groupId>
    <artifactId>Parent</artifactId>
    <version>0.0.1</version>
    // 使用relativePath标签什么父工程pom的相对路径。相对于当前pom文件的路径
    <relativePath>../Parent/pom.xml</relativePath>
</parent>

<dependencies>
    <dependency>
        <groupId>junit</groupId>
        <artifactId>junit</artifactId>
        <scope>test</scope>
    </dependency>
</dependencies>

聚合

在上述继承中，我们提到了一点，在配置继承后，执行安装命令时要先安装父工程。
这是由于如果不先安装父工程，在本地仓库中是找不到父工程的，会导致安装出错。

解决上述问题，可以采用以下配置，在父工程pom文件中配置<modules>标签，用于声明项目安装的顺序，这样就不会出现上述的问题。

父工程pom.xml

<modelVersion>4.0.0</modelVersion>
<groupId>com.arcc.demo</groupId>
<artifactId>Parent</artifactId>
<version>0.0.1</version>
<packaging>pom</packaging>

// 配置聚合,使用相对路径
<modules>
    <module>../Son1</module>
    <module>../Son2</module>
    ......
</modules>

// 配置依赖的管理
<dependencyManagement>
    <dependencies>
        <dependency>
            <groupId>junit</groupId>
            <artifactId>junit</artifactId>
            <version>4.0</version>
            <scope>test</scope>
        </dependency>
    </dependencies>
</dependencyManagement>

配置完成后，直接在父工程中使用mvn install命令，Maven会根据依赖关系，自动调整安装顺序，不需要指定安装的顺序。

自动化构建

可以通过配置<build>标签实现自动化部署的功能，不过企业中不常用，这里就不总结了。

补充

我们可以到http://mvnrepository.com搜索需要的jar包的依赖信息