使用Maven管理项目、导入依赖、测试打包项目、常用依赖

使用Maven管理项目

Maven 翻译为"专家"、“内行”，是 Apache 下的一个纯 Java 开发的开源项目。基于项目对象模型（缩写：POM）概念，Maven利用一个中央信息片断能管理一个项目的构建、报告和文档等步骤。Maven 是一个项目管理工具，可以对 Java 项目进行构建、依赖管理。Maven 也可被用于构建和管理各种项目，例如 C#，Ruby，Scala 和其他语言编写的项目。Maven 曾是 Jakarta 项目的子项目，现为由 Apache 软件基金会主持的独立 Apache 项目。

通过Maven，可以帮助我们做：

• 项目的自动构建，包括代码的编译、测试、打包、安装、部署等操作
• 依赖管理，项目使用到哪些依赖，可以快速完成导入

导入依赖的时候，每次都要去下载对应的Jar包，这样其实是很麻烦的，并且还有可能一个Jar包依赖于另一个Jar包，就像之前使用JUnit一样，因此需要一个更加方便的包管理机制

Maven也需要安装环境，但是IDEA已经自带了Maven环境，因此不需要再去进行额外的环境安装（无IDEA也能使用Maven，但是配置过程很麻烦，并且我们现在使用的都是IDEA的集成开发环境，所以这里就不讲解Maven命令行操作了）我们直接创建一个新的Maven项目即可

Maven项目结构

Maven项目和我们普通的项目有什么区别：

先创建一个maven项目

resource：存放一些静态文件，如配置文件

在Java包下创建类，与寻常Java项目创建类大差不差，之后输出第一行代码

test：里面的用于测试，可结合Junit一起使用，稍后在进行笔记

POM文件，相当于是整个Maven项目的配置文件，使用XML编写：

<?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"> <!--根节点-->
    <modelVersion>4.0.0</modelVersion> <!--模块版本-->

    <groupId>org.example</groupId> <!--指定组名称-->
    <artifactId>MavenTest</artifactId> <!--指定项目在当前组中的唯一名称-->
    <version>1.0-SNAPSHOT</version> <!--代表项目版本，可以自定-->

    <properties> <!-坐标-->
        <maven.compiler.source>8</maven.compiler.source>
        <maven.compiler.target>8</maven.compiler.target>
    </properties>

</project>

Maven的配置文件是以project为根节点，而modelVersion定义了当前模型的版本，一般是4.0.0，不用去修改

项目的基本坐标

groupId、artifactId、version这三个元素合在一起，用于唯一区别每个项目，别人如果需要将编写的代码作为依赖，那么就必须通过这三个元素来定位项目，称为一个项目的基本坐标，所有的项目一般都有自己的Maven坐标，因此通过Maven导入其他的依赖只需要填写这三个基本元素就可以了，无需再下载Jar文件，而是Maven自动帮助下载依赖并导入。

• groupId 一般用于指定组名称，命名规则一般和包名一致，比如这里使用的是org.example，一个组下面可以有很多个项目
• artifactId 一般用于指定项目在当前组中的唯一名称，也就是说在组中用于区分于其他项目的标记
• version 代表项目版本，随着我们项目的开发和改进，版本号也会不断更新，可以手动指定当前项目的版本号，其他人使用我们的项目作为依赖时，也可以根本版本号进行选择（这里的SNAPSHOT代表快照，一般表示这是一个处于开发中的项目，正式发布项目一般只带版本号）

properties中一般都是一些变量和选项的配置，这里指定了JDK的源代码和编译版本为1.8，无需进行修改。

Maven依赖导入

导入之前的JDBC驱动依赖、JUnit依赖、Mybatis依赖、Lombok依赖，那么如何使用Maven来管理依赖？

可以创建一个dependencies节点：

<dependencies>
    <!--里面填写的就是所有的依赖-->
</dependencies>

那么现在就可以向节点中填写依赖了，那么如何知道每个依赖的坐标呢？可以在该网站 进行查询，搜索lombok，点击版本号后可以看到已经给我们写出了依赖的坐标：

之后，等待Maven导入依赖，刷新Maven仓库，就会发现Jar包自动被导入

<!-- https://mvnrepository.com/artifact/org.projectlombok/lombok -->
<dependency>
    <groupId>org.projectlombok</groupId>
    <artifactId>lombok</artifactId>
    <version>1.18.26</version>
    <scope>provided</scope>
</dependency>

将其添加到dependencies节点中，编写一个测试用例看看依赖导入是否成功：

public class Main {
    public static void main(String[] args) {
        Student student = new Student("小明", 18);
        System.out.println(student);
    }
}

@Data
@AllArgsConstructor
public class Student {
    String name;
    int age;
}

项目运行成功，表示成功导入了依赖。那么，Maven是如何进行依赖管理呢，以致于如此便捷的导入依赖，我们来看看Maven项目的依赖管理流程：

通过流程图我们得知，一个项目依赖一般是存储在中央仓库中，也有可能存储在一些其他的远程仓库（私服），几乎所有的依赖都被放到了中央仓库中，因此，Maven可以直接从中央仓库中下载大部分的依赖（Maven第一次导入依赖是需要联网的），远程仓库中下载之后 ，会暂时存储在本地仓库，发现本地存在一个.m2文件夹，这就是Maven本地仓库文件夹，默认建立在C盘，如果你C盘空间不足，会出现问题

在下次导入依赖时，如果Maven发现本地仓库中就已经存在某个依赖，那么就不会再去远程仓库下载了。

可能在导入依赖时，会出现卡顿的问题，建议配置一下IDEA自带的Maven插件远程仓库地址，打开IDEA的安装目录，找到安装根目录/plugins/maven/lib/maven3/conf文件夹，找到settings.xml文件，打开编辑：

找到mirros标签，添加以下内容：

<mirror>
      <id>nexus-aliyun</id>
      <mirrorOf>*</mirrorOf>
      <name>Nexus aliyun</name>
      <url>http://maven.aliyun.com/nexus/content/groups/public</url>
</mirror> 

这样，就将默认的远程仓库地址（国外），配置为国内的阿里云仓库地址了（依赖的下载速度就会快起来了）

Maven依赖作用域

除了三个基本的属性用于定位坐标外，依赖还可以添加以下属性：

• type：依赖的类型，对于项目坐标定义的packaging。大部分情况下，该元素不必声明，其默认值为jar
• scope：依赖的范围（作用域，着重讲解）
• optional：标记依赖是否可选
• exclusions：用来排除传递性依赖（一个项目有可能依赖于其他项目，就像别人要用我们的项目作为依赖，那么就需要一起下载项目的依赖，如Lombok）

着重来讲解一下scope属性，它决定了依赖的作用域范围：

• compile ：为默认的依赖有效范围。如果在定义依赖关系的时候，没有明确指定依赖有效范围的话，则默认采用该依赖有效范围。此种依赖，在编译、运行、测试时均有效。
• provided ：在编译、测试时有效，但是在运行时无效，也就是说，项目在运行时，不需要此依赖，比如我们上面的Lombok，我们只需要在编译阶段使用它，编译完成后，实际上已经转换为对应的代码了，因此Lombok不需要在项目运行时也存在。
• runtime ：在运行、测试时有效，但是在编译代码时无效。比如我们如果需要自己写一个JDBC实现，那么肯定要用到JDK为我们指定的接口，但是实际上在运行时是不用自带JDK的依赖，因此只保留我们自己写的内容即可。
• test ：只在测试时有效，例如：JUnit，我们一般只会在测试阶段使用JUnit，而实际项目运行时，我们就用不到测试了，那么我们来看看，导入JUnit的依赖：

同样的，可以在网站上搜索Junit的依赖，导入最新的JUnit5作为依赖：

<dependency>
    <groupId>org.junit.jupiter</groupId>
    <artifactId>junit-jupiter</artifactId>
    <version>5.8.1</version>
    <scope>test</scope>
</dependency>

所有的测试用例全部编写到Maven项目给我们划分的test目录下，位于此目录下的内容不会在最后被打包到项目中，只用作开发阶段测试使用：

public class MainTest {

    @Test
    public void test(){
        System.out.println("测试");
      	//Assert在JUnit5时名称发生了变化Assertions
        Assertions.assertArrayEquals(new int[]{1, 2, 3}, new int[]{1, 2});
    }
}

因此，一般仅用作测试的依赖如JUnit只保留在测试中即可，那么现在我们再来添加JDBC和Mybatis的依赖：

<dependency>
    <groupId>mysql</groupId>
    <artifactId>mysql-connector-java</artifactId>
    <version>8.0.27</version>
</dependency>
<dependency>
    <groupId>org.mybatis</groupId>
    <artifactId>mybatis</artifactId>
    <version>3.5.7</version>
</dependency>

我们发现，Maven还给我们提供了一个resource文件夹，我们可以将一些静态资源，比如配置文件，放入到这个文件夹中，项目在打包时会将资源文件夹中文件一起打包的Jar中，比如我们在这里编写一个Mybatis的配置文件：

<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE configuration
        PUBLIC "-//mybatis.org//DTD Config 3.0//EN"
        "http://mybatis.org/dtd/mybatis-3-config.dtd">
<configuration>
    <settings>
        <setting name="mapUnderscoreToCamelCase" value="true"/>
        <setting name="cacheEnabled" value="true"/>
        <setting name="logImpl" value="JDK_LOGGING" />
    </settings>
    <!-- 需要在environments的上方 -->
    <typeAliases>
        <package name="com.test.entity"/>
    </typeAliases>
    <environments default="development">
        <environment id="development">
            <transactionManager type="JDBC"/>
            <dataSource type="POOLED">
                <property name="driver" value="com.mysql.cj.jdbc.Driver"/>
                <property name="url" value="jdbc:mysql://localhost:3306/study"/>
                <property name="username" value="test"/>
                <property name="password" value="123456"/>
            </dataSource>
        </environment>
    </environments>
    <mappers>
        <mapper class="com.test.mapper.TestMapper"/>
    </mappers>
</configuration>

现在我们创建一下测试用例，顺便带大家了解一下Junit5的一些比较方便的地方：

public class MainTest {

    //因为配置文件位于内部，我们需要使用Resources类的getResourceAsStream来获取内部的资源文件
    private static SqlSessionFactory factory;

    //在JUnit5中@Before被废弃，它被细分了：
    @BeforeAll // 一次性开启所有测试案例只会执行一次 (方法必须是static)
    // @BeforeEach 一次性开启所有测试案例每个案例开始之前都会执行一次
    @SneakyThrows
    public static void before(){
        factory = new SqlSessionFactoryBuilder()
                .build(Resources.getResourceAsStream("mybatis-config.xml"));
    }


    @DisplayName("Mybatis数据库测试")  //自定义测试名称
    @RepeatedTest(3)  //自动执行多次测试
    public void test(){
        try (SqlSession sqlSession = factory.openSession(true)){
            TestMapper testMapper = sqlSession.getMapper(TestMapper.class);
            System.out.println(testMapper.getStudentBySid(1));
        }
    }
}

测试结果：

如果需要的依赖没有上传的远程仓库，而是只有一个Jar，可以使用第四种作用域：

• system：作用域和provided是一样的，但是它不是从远程仓库获取，而是直接导入本地Jar包：

<dependency>
     <groupId>javax.jntm</groupId>
     <artifactId>oha</artifactId>
     <version>2.0</version>
     <scope>system</scope> <!--作用范围改成system-->
     <systemPath>C://学习资料/4K高清无码/test.jar</systemPath>
</dependency>

比如上面的例子，如果scope为system，那么我们需要添加一个systemPath来指定jar文件的位置，这里就不再演示了。

Maven可选依赖

当项目中的某些依赖不希望被使用此项目作为依赖的项目使用时，我们可以给依赖添加optional标签表示此依赖是可选的，默认在导入依赖时，不会导入可选的依赖：

<optional>true</optional>

比如Mybatis的POM文件中，就存在大量的可选依赖：

<dependency>
  <groupId>org.slf4j</groupId>
  <artifactId>slf4j-api</artifactId>
  <version>1.7.30</version>
  <optional>true</optional>
</dependency>
<dependency>
  <groupId>org.slf4j</groupId>
  <artifactId>slf4j-log4j12</artifactId>
  <version>1.7.30</version>
  <optional>true</optional>
</dependency>
<dependency>
  <groupId>log4j</groupId>
  <artifactId>log4j</artifactId>
  <version>1.2.17</version>
  <optional>true</optional>
</dependency>
 ...

由于Mybatis要支持多种类型的日志，需要用到很多种不同的日志框架，因此需要导入这些依赖来做兼容，但是我们项目中并不一定会使用这些日志框架作为Mybatis的日志打印器，因此这些日志框架仅Mybatis内部做兼容需要导入使用，而我们可以选择不使用这些框架或是选择其中一个，也就是说导入Mybatis之后想用什么日志框架再自己加

Maven排除依赖

现在我们可以让使用此项目作为依赖的项目默认不使用可选依赖

如果存在那种不是可选依赖，也可以通过排除依赖来防止添加不必要的依赖：

<dependency>
    <groupId>org.junit.jupiter</groupId>
    <artifactId>junit-jupiter</artifactId>
    <version>5.8.1</version>
    <scope>test</scope>
    <exclusions>
        <exclusion>
            <groupId>org.junit.jupiter</groupId>
            <artifactId>junit-jupiter-engine</artifactId>
        </exclusion>
    </exclusions>
</dependency>

Maven继承关系

一个Maven项目可以继承自另一个Maven项目，比如多个子项目都需要父项目的依赖，我们就可以使用继承关系来快速配置。

我们右键左侧栏，新建一个模块，来创建一个子项目，查看他的pom.xml：

再来看父类的pom，新增了一个modules：

IDEA默认加了一个parent节点，表示此Maven项目是父Maven项目的子项目，子项目直接继承父项目的groupId，子项目会直接继承父项目的所有依赖，除非依赖添加了optional标签，测试一下:

import lombok.extern.java.Log;
@Log
public class Main {
    public static void main(String[] args) {
        log.info("我是日志信息");
    }
}

可以看到，子项目也成功继承了Lombok依赖。

我们还可以让父Maven项目统一管理所有的依赖，包括版本号等，子项目可以选取需要的作为依赖，而版本全由父项目管理，我们可以将dependencies全部放入dependencyManagement节点，这样父项目就完全作为依赖统一管理。

<dependencyManagement>
    <dependencies>
        <dependency>
            <groupId>org.projectlombok</groupId>
            <artifactId>lombok</artifactId>
            <version>1.18.22</version>
            <scope>provided</scope>
        </dependency>
        <dependency>
            <groupId>org.junit.jupiter</groupId>
            <artifactId>junit-jupiter</artifactId>
            <version>5.8.1</version>
            <scope>test</scope>
        </dependency>
        <dependency>
            <groupId>mysql</groupId>
            <artifactId>mysql-connector-java</artifactId>
            <version>8.0.27</version>
        </dependency>
        <dependency>
            <groupId>org.mybatis</groupId>
            <artifactId>mybatis</artifactId>
            <version>3.5.7</version>
        </dependency>
    </dependencies>
</dependencyManagement>

我们发现，子项目的依赖失效了，因为现在父项目没有依赖，而是将所有的依赖进行集中管理，子项目需要什么再拿什么，同时子项目无需指定版本，所有的版本全部由父项目决定，子项目导入即可：

当然，父项目如果还存在dependencies节点的话，里面的内依赖依然是直接继承：

<dependencies>
    <dependency>
        <groupId>org.junit.jupiter</groupId>
        <artifactId>junit-jupiter</artifactId>
        <version>5.8.1</version>
        <scope>test</scope>
    </dependency>
</dependencies>

<dependencyManagement>
    <dependencies>
      ...

Maven常用命令

在IDEA右上角Maven板块中，每个Maven项目都有一个生命周期，实际上这些是Maven的一些插件，每个插件都有各自的功能，比如：

• clean命令，执行后会清理整个target文件夹，在之后编写Springboot项目时可以解决一些缓存没更新的问题。
• validate命令可以验证项目的可用性。
• compile命令可以将项目编译为.class文件。
• install命令可以将当前项目安装到本地仓库，以供其他项目导入作为依赖使用
• verify命令可以按顺序执行每个默认生命周期阶段（validate，compile，package等）

如果不直接点击的话，也可以通过敲击命令行来进行

Maven测试项目

通过使用test命令，可以一键测试所有位于test目录下的测试案例，请注意有以下要求：

• 测试类的名称必须是以Test结尾，比如MainTest
• 测试方法上必须标注@Test注解，实测@RepeatedTest无效

这是由于JUnit5比较新，我们需要重新配置插件升级到高版本，才能完美的兼容Junit5：

<build>
    <plugins>
        <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-surefire-plugin</artifactId>
            <!-- JUnit 5 requires Surefire version 2.22.0 or higher -->
            <version>2.22.0</version>
        </plugin>
    </plugins>
</build>

现在@RepeatedTest、@BeforeAll也能使用了。

Maven打包项目

项目在编写完成之后，要么作为Jar依赖，供其他模型使用，要么就作为一个可以执行的程序，在控制台运行，只需要直接执行package命令就可以直接对项目的代码进行打包，生成jar文件

在执行package命令时，会先执行一遍test命令，以防万一

当然，以上方式仅适用于作为Jar依赖的情况，如果需要打包一个可执行文件，那么不仅需要将自己编写的类打包到Jar中，同时还需要将依赖也一并打包到Jar中，因为使用了别人提供的框架，自然也需要运行别人的代码，需要使用另一个插件来实现一起打包：

<plugin>
    <artifactId>maven-assembly-plugin</artifactId>
    <version>3.1.0</version>
    <configuration>
        <descriptorRefs>
            <descriptorRef>jar-with-dependencies</descriptorRef>
        </descriptorRefs>
        <archive>
            <manifest>
                <addClasspath>true</addClasspath>
                <mainClass>com.test.Main</mainClass>
            </manifest>
        </archive>
    </configuration>
    <executions>
        <execution>
            <id>make-assembly</id>
            <phase>package</phase>
            <goals>
                <goal>single</goal>
            </goals>
        </execution>
    </executions>
</plugin>

在打包之前也会执行一次test命令，来保证项目能够正常运行，当测试出现问题时，打包将无法完成，也可以手动跳过，选择执行Maven目标来手动执行Maven命令，输入mvn package -Dmaven.test.skip=true 来以跳过测试的方式进行打包。

最后得到Jar文件，在同级目录下输入java -jar xxxx.jar来运行打包好的Jar可执行程序（xxx代表文件名称）

此时能看到JAR包

• deploy命令用于发布项目到本地仓库和远程仓库，一般情况下用不到，这里就不做讲解了。
• site命令用于生成当前项目的发布站点，暂时不需要了解。