Spring---Maven高级

最新推荐文章于 2024-08-01 21:58:27 发布

小夫敲代码

最新推荐文章于 2024-08-01 21:58:27 发布

阅读量1.1k

点赞数 3

分类专栏： Sping 文章标签： maven java 开发语言

本文链接：https://blog.csdn.net/weixin_65440201/article/details/126421909

版权

Sping 专栏收录该内容

12 篇文章 0 订阅

订阅专栏

1.分模块开发

1.1分模块开发设计

分模块开发设计的分类：

1.按照功能进行拆分(防止多个业务之间，由于某一个业务出现问题而影响全部业务)

2.按照模块进行拆分(通过添加模块依赖可以解决代码冗余)

将原始模块按照功能拆分成若干个子模块，方便模块间的相互调用，接口共享。

刚刚我们说了可以将 domain 层进行拆分，除了 domain 层，我们也可以将其他的层也拆成一个个对

立的模块，如 :

1.2 分模块开发实现

前面我们已经完成了 SSM 整合，接下来，咱们就基于 SSM 整合的项目来实现对项目的拆分。

1.2.1 环境准备

将资料 \maven_02_ssm 部署到 IDEA 中，将环境快速准备好，部署成功后，项目的格式如下 :

1.2.2 抽取domain层

步骤 1: 创建新模块

创建一个名称为 maven_03_pojo 的 jar 项目 , 为什么项目名是从 02 到 03 这样创建，原因后面我们会提

到，这块的名称可以任意。

步骤 2: 项目中创建 domain 包

在 maven_03_pojo 项目中创建 com.itheima.domain 包，并将 maven_02_ssm 中 Book 类拷贝到该包

中

步骤 3: 删除原项目中的 domain 包

删除后， maven_02_ssm 项目中用到 Book 的类中都会有红色提示，如下 :

说明 : 出错的原因是 maven_02_ssm 中已经将 Book 类删除，所以该项目找不到 Book 类，所以报错

要想解决上述问题，我们需要在 maven_02_ssm 中添加 maven_03_pojo 的依赖。

步骤 4: 建立依赖关系

在 maven_02_ssm 项目的 pom.xml 添加 maven_03_pojo 的依赖

<dependency> 
    <groupId>com.itheima</groupId> 
    <artifactId>maven_03_pojo</artifactId> 
    <version>1.0-SNAPSHOT</version> 
</dependency>

因为添加了依赖，所以在 maven_02_ssm 中就已经能找到 Book 类，所以刚才的报红提示就会消

失。

步骤5:编译maven_02_ssm项目

编译 maven_02_ssm 你会在控制台看到如下错误

错误信息为：不能解决 maven_02_ssm 项目的依赖问题，找不到 maven_03_pojo 这个 jar 包。

为什么找不到呢 ?

原因是 Maven 会从本地仓库找对应的 jar 包，但是本地仓库又不存在该 jar 包所以会报错。

在 IDEA 中是有 maven_03_pojo 这个项目，所以我们只需要将 maven_03_pojo 项目安装到本地仓库

即可。

步骤 6: 将项目安装本地仓库

将需要被依赖的项目 maven_03_pojo ，使用 maven 的 install 命令，把其安装到 Maven 的本地仓库

中。

安装成功后，在对应的路径下就看到安装好的jar包

说明:具体安装在哪里，和你们自己电脑上Maven的本地仓库配置的位置有关。

当再次执行 maven_02_ssm 的 compile 的命令后，就已经能够成功编译。

1.2.3 抽取Dao层

步骤 1: 创建新模块

创建一个名称为 maven_04_dao 的 jar 项目

步骤2:项目中创建dao包

在maven_04_dao项目中创建com.itheima.dao包，并将maven_02_ssm中BookDao类拷贝到该包

中

在 maven_04_dao 中会有如下几个问题需要解决下 :

项目 maven_04_dao 的 BookDao 接口中 Book 类找不到报错

解决方案在 maven_04_dao 项目的 pom.xml 中添加 maven_03_pojo 项目

        <dependency>
            <groupId>com.itheima</groupId>
            <artifactId>maven_03_pojo</artifactId>
            <version>1.0-SNAPSHOT</version>
        </dependency>

项目 maven_04_dao 的 BookDao 接口中， Mybatis 的增删改查注解报错

解决方案在 maven_04_dao 项目的 pom.xml 中添加 mybatis 的相关依赖

        <dependency>
            <groupId>org.mybatis</groupId>
            <artifactId>mybatis</artifactId>
            <version>3.5.6</version>
        </dependency>

        <dependency>
            <groupId>mysql</groupId>
            <artifactId>mysql-connector-java</artifactId>
            <version>5.1.47</version>
        </dependency>

步骤 3: 删除原项目中的 dao 包

删除 Dao 包以后，因为 maven_02_ssm 中的 BookServiceImpl 类中有使用到 Dao 的内容，所以需要

在 maven_02_ssm 的 pom.xml 添加 maven_04_dao 的依赖

    <!--依赖dao运行-->
    <dependency>
      <groupId>com.itheima</groupId>
      <artifactId>maven_04_dao</artifactId>
      <version>1.0-SNAPSHOT</version>

此时在 maven_02_ssm 项目中就已经添加了 maven_03_pojo 和 maven_04_dao 包

再次对maven_02_ssm项目进行编译，又会报错，如下

和刚才的错误原因是一样的， maven 在仓库中没有找到 maven_04_dao , 所以此时我们只需要将

maven_04_dao 安装到 Maven 的本地仓库即可。

步骤 4: 将项目安装到本地仓库

将需要被依赖的项目 maven_04_dao ，使用 maven 的 install 命令，把其安装到 Maven 的本地仓库

中

安装成功后，在对应的路径下就看到了安装好对应的jar包

当再次执行 maven_02_ssm 的 compile 的指令后，就已经能够成功编译。

1.2.4 运行测试并总结

将抽取后的项目进行运行，测试之前的增删改查功能依然能够使用。

所以对于项目的拆分，大致会有如下几个步骤 :

(1) 创建 Maven 模块

(2) 书写模块代码

分模块开发需要先针对模块功能进行设计，再进行编码。不会先将工程开发完毕，然后进行拆分。拆

分方式可以按照功能拆也可以按照模块拆。

(3) 通过 maven 指令安装模块到本地仓库 (install 指令 )

团队内部开发需要发布模块功能到团队内部可共享的仓库中 ( 私服 ) ，私服我们后面会讲解。

2 ，依赖管理

我们现在已经能把项目拆分成一个个独立的模块，当在其他项目中想要使用独立出来的这些模块，

只需要在其 pom.xml 使用标签来进行 jar 包的引入即可。

其实就是依赖，关于依赖管理里面都涉及哪些内容，我们就一个个来学习下 :

依赖传递

可选依赖

排除依赖

我们先来说说什么是依赖 : 依赖指当前项目运行所需的 jar ，一个项目可以设置多个依赖。

格式为 :

2.1 依赖传递与冲突问题

回到我们刚才的项目案例中，打开 Maven 的面板，你会发现 :

在项目所依赖的这些jar包中，有一个比较大的区别就是有的依赖前面有箭头> ,有的依赖前面没有。

那么这个箭头所代表的含义是什么 ?

打开前面的箭头，你会发现这个 jar 包下面还包含有其他的 jar 包

你会发现有两个maven_03_pojo的依赖被加载到Dependencies中，那么maven_04_dao中的

maven_03_pojo 能不能使用呢 ?

要想验证非常简单，只需要把 maven_02_ssm 项目中 pom.xml 关于 maven_03_pojo 的依赖注释或删

除掉

在 Dependencies 中移除自己所添加 maven_03_pojo 依赖后，打开 BookServiceImpl 的类，你会发

现 Book 类依然存在，可以被正常使用

这个特性其实就是我们要讲解的 依赖传递 。

依赖是具有传递性的 :

说明 : A 代表自己的项目； B,C,D,E,F,G 代表的是项目所依赖的 jar 包； D1 和 D2 E1 和 E2 代表是相同 jar 包的不同版本

(1) A 依赖了 B 和 C,B 和 C 有分别依赖了其他 jar 包，所以在 A 项目中就可以使用上面所有 jar 包，这就是所说的依赖传递

(2) 依赖传递有直接依赖和间接依赖

相对于 A 来说， A 直接依赖 B 和 C, 间接依赖了 D1,E1,G ， F,D2 和 E2

相对于 B 来说， B 直接依赖了 D1 和 E1, 间接依赖了 G

直接依赖和间接依赖是一个相对的概念

(3) 因为有依赖传递的存在，就会导致 jar 包在依赖的过程中出现冲突问题，具体什么是冲突 ?Maven是如何解决冲突的 ?

这里所说的 依赖冲突 是指项目依赖的某一个 jar 包，有多个不同的版本，因而造成类包版本冲突。

情况一 : 在 maven_02_ssm 的 pom.xml 中添加两个不同版本的 Junit 依赖 :

通过对比，会发现一个结论

特殊优先：当同级配置了相同资源的不同版本，后配置的覆盖先配置的。

情况二 : 路径优先：当依赖中出现相同的资源时，层级越深，优先级越低，层级越浅，优先级越高

A 通过 B 间接依赖到 E1

A 通过 C 间接依赖到 E2

A 就会间接依赖到 E1 和 E2,Maven 会按照层级来选择， E1 是 2 度， E2 是 3 度，所以最终会选择 E1

情况三 : 声明优先：当资源在相同层级被依赖时，配置顺序靠前的覆盖配置顺序靠后的

A 通过 B 间接依赖到 D1

A 通过 C 间接依赖到 D2

D1 和 D2 都是两度，这个时候就不能按照层级来选择，需要按照声明来，谁先声明用谁，也就是说 B在 C 之前声明，这个时候使用的是 D1 ，反之则为 D2

但是对应上面这些结果，大家不需要刻意去记它。因为不管 Maven 怎么选，最终的结果都会在 Maven 的 Dependencies面板中展示出来，展示的是哪个版本，也就是说它选择的就是哪个版本，如:

如果想更全面的查看Maven中各个坐标的依赖关系，可以点击Maven面板中的show Dependencies

2.2 可选依赖和排除依赖

2.2.1 方案一:可选依赖

可选依赖指对外隐藏当前所依赖的资源---不透明

在 maven_04_dao 的 pom.xml, 在引入 maven_03_pojo 的时候，添加 optional

        <dependency>
            <groupId>com.itheima</groupId>
            <artifactId>maven_03_pojo</artifactId>
            <version>1.0-SNAPSHOT</version>
            <!--可选依赖是隐藏当前工程所依赖的资源，隐藏后对应资源将不具有依赖传递性-->
            <optional>false</optional>
        </dependency>

此时 BookServiceImpl 就已经报错了 , 说明由于 maven_04_dao 将 maven_03_pojo 设置成可选依

赖，导致 maven_02_ssm 无法引用到 maven_03_pojo 中的内容，导致 Book 类找不到。

2.2.2方案二:排除依赖

排除依赖指主动断开依赖的资源，被排除的资源无需指定版本---不需要

前面我们已经通过可选依赖实现了阻断 maven_03_pojo 的依赖传递，对于排除依赖，则指的是已经

有依赖的事实，也就是说 maven_02_ssm 项目中已经通过依赖传递用到了 maven_03_pojo ，此时

我们需要做的是将其进行排除，所以接下来需要修改 maven_02_ssm 的 pom.xml

      <!--排除依赖是隐藏当前资源对应的依赖关系-->
      <exclusions>
        <exclusion>
          <groupId>log4j</groupId>
          <artifactId>log4j</artifactId>
        </exclusion>
        <exclusion>
          <groupId>org.mybatis</groupId>
          <artifactId>mybatis</artifactId>
        </exclusion>
      </exclusions>
    </dependency>

这样操作后， BookServiceImpl 中的 Book 类一样也会报错。

当然 exclusions 标签带 s 说明我们是可以依次排除多个依赖到的 jar 包，比如 maven_04_dao 中有依

赖 junit 和 mybatis, 我们也可以一并将其排除

A 依赖 B,B 依赖 C , C 通过依赖传递会被 A 使用到，现在要想办法让 A 不去依赖 C

可选依赖是在 B 上设置 <optional> , A 不知道有 C 的存在，

排除依赖是在 A 上设置 <exclusions> , A 知道有 C 的存在，主动将其排除掉。

3，聚合和继承

3.1聚合

分模块开发后，需要将这四个项目都安装到本地仓库，目前我们只能通过项目 Maven 面板的

install 来安装，并且需要安装四个，如果我们的项目足够多，那么一个个安装起来还是比较麻烦的

如果四个项目都已经安装成功，当 ssm_pojo 发生变化后，我们就得将 ssm_pojo 重新安装到

maven 仓库，但是为了确保我们对 ssm_pojo 的修改不会影响到其他项目模块，我们需要对所有的模块进行重新编译，那又需要将所有的模块再来一遍

项目少的话还好，但是如果项目多的话，一个个操作项目就容易出现漏掉或重复操作的问题，所以我们就想能不能抽取一个项目，把所有的项目管理起来，以后我们要想操作这些项目，只需要操作这一个项目，其他所有的项目都走一样的流程，这个不就很省事省力。

这就用到了我们接下来要讲解的聚合，

所谓聚合:将多个模块组织成一个整体，同时进行项目构建的过程称为聚合

聚合工程：通常是一个不具有业务功能的"空"工程（有且仅有一个pom文件）

作用：使用聚合工程可以将多个工程编组，通过对聚合工程进行构建，实现对所包含的模块进行同步构建

当工程中某个模块发生更新（变更）时，必须保障工程中与已更新模块关联的模块同步更新，此时可以使用聚合工程来解决批量模块同步构建的问题。

关于聚合具体的实现步骤为 :

步骤1:创建一个空的maven项目

步骤2:将项目的打包方式改为pom

<?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>com.itheima</groupId>
    <artifactId>maven_01_parent</artifactId>
    <version>1.0-RELEASE</version>
    <packaging>pom</packaging>

说明 : 项目的打包方式，我们接触到的有三种，分别是

jar: 默认情况，说明该项目为 java 项目

war: 说明该项目为 web 项目

pom: 说明该项目为聚合或继承 ( 后面会讲 ) 项目

步骤3:pom.xml添加所要管理的项目

    <!--设置管理的模块名称-->
    <modules>
        <module>../maven_02_ssm</module>
        <module>../maven_03_pojo</module>
        <module>../maven_04_dao</module>
    </modules>

步骤4:使用聚合统一管理项目

测试发现，当 maven_01_parent 的 compile 被点击后，所有被其管理的项目都会被执行编译操作。这就是聚合工程的作用。

说明：聚合工程管理的项目在进行运行的时候，会按照项目与项目之间的依赖关系来自动决定执行的顺序和配置的顺序无关。聚合工程主要是用来管理项目 。

3.2 继承

spring-webmvc、spring-jdbc在三个项目模块中都有出现，这样就出现了重复的内容

spring - test 只在 ssm_crm 和 ssm_goods 中出现，而在 ssm_order 中没有，这里是部分重复的内

容

我们使用的 spring 版本目前是 5.2.10.RELEASE , 假如后期要想升级 spring 版本，所有跟 Spring

相关 jar 包都得被修改，涉及到的项目越多，维护成本越高

面对上面的这些问题，我们就得用到接下来要学习的继承

所谓继承:描述的是两个工程间的关系，与java中的继承相似，子工程可以继承父工程中的配置信

息，常见于依赖关系的继承。

作用：

简化配置

减少版本冲突

步骤 1: 创建一个空的 Maven 项目并将其打包方式设置为 pom

因为这一步和前面 maven 创建聚合工程的方式是一摸一样，所以我们可以单独创建一个新的工程，也可以直接和聚合公用一个工程。实际开发中，聚合和继承一般也都放在同一个项目中，但是这两个的功能是不一样的。

步骤 2: 在子项目中设置其父工程

分别在 maven_02_ssm , maven_03_pojo , maven_04_dao 的 pom.xml 中添加其父项目为 maven_01_parent

步骤3:优化子项目共有依赖导入问题

1. 将子项目共同使用的 jar 包都抽取出来，维护在父项目的 pom.xml 中

    <dependencies>
        <dependency>
            <groupId>org.springframework</groupId>
            <artifactId>spring-core</artifactId>
            <version>${spring.version}</version>
        </dependency>

        <dependency>
            <groupId>org.springframework</groupId>
            <artifactId>spring-webmvc</artifactId>
            <version>${spring.version}</version>
        </dependency>

        <dependency>
            <groupId>org.springframework</groupId>
            <artifactId>spring-jdbc</artifactId>
            <version>${spring.version}</version>
        </dependency>

        <dependency>
            <groupId>org.springframework</groupId>
            <artifactId>spring-test</artifactId>
            <version>${spring.version}</version>
        </dependency>

        <dependency>
            <groupId>org.mybatis</groupId>
            <artifactId>mybatis</artifactId>
            <version>3.5.6</version>
        </dependency>

        <dependency>
            <groupId>org.mybatis</groupId>
            <artifactId>mybatis-spring</artifactId>
            <version>${mybatis-spring.version}</version>
        </dependency>

        <dependency>
            <groupId>mysql</groupId>
            <artifactId>mysql-connector-java</artifactId>
            <version>5.1.47</version>
        </dependency>

        <dependency>
            <groupId>com.alibaba</groupId>
            <artifactId>druid</artifactId>
            <version>1.1.16</version>
        </dependency>

        <dependency>
            <groupId>javax.servlet</groupId>
            <artifactId>javax.servlet-api</artifactId>
            <version>3.1.0</version>
            <scope>provided</scope>
        </dependency>

        <dependency>
            <groupId>com.fasterxml.jackson.core</groupId>
            <artifactId>jackson-databind</artifactId>
            <version>2.9.0</version>
        </dependency>
    </dependencies>

2. 删除子项目中已经被抽取到父项目的 pom.xml 中的 jar 包，如在 maven_02_ssm 的 pom.xml 中将已

经出现在父项目的 jar包删除掉，删除完后，你会发现父项目中有依赖对应的 jar 包，子项目虽然已经将重复的依赖删除掉了，但是刷新的时候，子项目中所需要的 jar 包依然存在。

当项目的 <parent> 标签被移除掉，会发现多出来的 jar 包依赖也会随之消失。

3. 将 maven_04_dao 项目的 pom.xml 中的所有依赖删除，然后添加上 maven_01_parent 的父项目坐

标，刷新并查看 Maven 的面板，会发现 maven_04_dao 同样引入了父项目中的所有依赖。

这样我们就可以解决刚才提到的第一个问题，将子项目中的公共 jar 包抽取到父工程中进行统一添加依赖，这样做的可以简化配置，并且当父工程中所依赖的 jar 包版本发生变化，所有子项目中对应的 jar 包版本也会跟着更新。

步骤 4: 优化子项目依赖版本问题

如果把所有用到的 jar 包都管理在父项目的 pom.xml ，看上去更简单些，但是这样就会导致有很多项

目引入了过多自己不需要的 jar 包。

1. 在父工程 mavne_01_parent 的 pom.xml 来定义依赖管理

    <!--定义依赖管理-->
    <dependencyManagement>
        <dependencies>
            <dependency>
                <groupId>junit</groupId>
                <artifactId>junit</artifactId>
                <version>${junit.version}</version>
                <scope>test</scope>
            </dependency>
        </dependencies>
    </dependencyManagement>

2. 将 maven_02_ssm 的 pom.xml 中的 junit 依赖删除掉，刷新 Maven

刷新完会发现，在 maven_02_ssm 项目中的 junit 依赖并没有出现，所以我们得到一个结论 :

<dependencyManagement> 标签不真正引入 jar 包，而是配置可供子项目选择的 jar 包依赖

子项目要想使用它所提供的这些 jar 包，需要自己添加依赖，并且不需要指定 <version>

3. 在 maven_02_ssm 的 pom.xml 添加 junit 的依赖

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

注意：这里就不需要添加版本了，这样做的好处就是当父工程 dependencyManagement 标签中的版本发生变化后，子项目中的依赖版本也会跟着发生变化

4. 在 maven_04_dao 的 pom.xml 添加 junit 的依赖

这个时候， maven_02_ssm 和 maven_04_dao 这两个项目中的 junit 版本就会跟随着父项目中的标签

dependencyManagement 中 junit 的版本发生变化而变化。不需要 junit 的项目就不需要添加对应

的依赖即可。

总结来说，继承可以帮助做两件事

将所有项目公共的 jar 包依赖提取到父工程的 pom.xml 中，子项目就可以不用重复编写，简化开发

将所有项目的 jar 包配置到父工程的 dependencyManagement 标签下，实现版本管理，方便维护

dependencyManagement 标签不真正引入 jar 包，只是管理 jar 包的版本

子项目在引入的时候，只需要指定 groupId 和 artifactId ，不需要加 version

当 dependencyManagement 标签中 jar 包版本发生变化，所有子项目中有用到该 jar 包的地方

对应的版本会自动随之更新

最后总结一句话就是， 父工程主要是用来快速配置依赖 jar 包和管理项目中所使用的资源 。

3.2.1小结

继承的实现步骤 :

1.创建 Maven 模块，设置打包类型为 pom

2.在父工程的 pom 文件中配置依赖关系 ( 子工程将沿用父工程中的依赖关系 ), 一般只抽取子项目中公

有的 jar 包

3.在父工程中配置子工程中可选的依赖关系

4.在子工程中配置当前工程所继承的父工程

5.在子工程中配置使用父工程中可选依赖的坐标

注意事项 :

1. 子工程中使用父工程中的可选依赖时，仅需要提供群组 id 和项目 id ，无需提供版本，版本由父

工程统一提供，避免版本冲突

2. 子工程中还可以定义父工程中没有定义的依赖关系 , 只不过不能被父工程进行版本统一管理

3.3 聚合与继承的区别

3.3.1 聚合与继承的区别

两种之间的作用:

        聚合用于快速构建项目，对项目进行管理

        继承用于快速配置和管理子项目中所使用jar 包的版本

聚合和继承的相同点:

        聚合与继承的pom.xml 文件打包方式均为 pom ，可以将两种关系制作到同一个 pom 文件中

        聚合与继承均属于设计型模块，并无实际的模块内容

聚合和继承的不同点:

        聚合是在当前模块中配置关系，聚合可以感知到参与聚合的模块有哪些

        继承是在子模块中配置关系，父模块无法感知哪些子模块继承了自己

3.3.2 IDEA 构建聚合与继承工程

其实对于聚合和继承工程的创建， IDEA 已经能帮助我们快速构建，具体的实现步骤为 :

步骤 1: 创建一个 Maven 项目

创建一个空的 Maven 项目，可以将项目中的 src 目录删除掉，这个项目作为聚合工程和父工程。

步骤 2: 创建子项目

该项目可以被聚合工程管理，同时会继承父工程。

创建成功后， maven_parent 即是聚合工程又是父工程， maven_web 中也有 parent 标签，继承的就

是 maven_parent, 对于难以配置的内容都自动生成。

按照上面这种方式，大家就可以根据自己的需要来构建分模块项目。

4，属性

4.1 属性

4.1.1依赖版本管理

4.1.2 解决步骤

步骤 1: 父工程中定义属性

步骤2:修改依赖的version此时，我们只需要更新父工程中properties标签中所维护的jar包版本，所有子项目中的版本也就跟

着更新。

4.2 配置文件加载属性

步骤1:父工程定义属性

步骤 2:jdbc.properties 文件中引用属性

在 jdbc.properties ，将 jdbc.url 的值直接获取 Maven 配置的属性

步骤 3: 设置 maven 过滤文件范围

Maven 在默认情况下是从当前项目的 src\main\resources 下读取文件进行打包。现在我们需要打包

的资源文件是在 maven_02_ssm 下 , 需要我们通过配置来指定下具体的资源目录。

说明 : directory 路径前要添加 ../ 的原因是 maven_02_ssm 相对于父工程的 pom.xml 路径是在其上

一层的目录中，所以需要添加。

修改完后，注意 maven_02_ssm 项目的 resources目录就多了些东西，如下:

步骤 4: 测试是否生效

测试的时候，只需要将 maven_02_ssm 项目进行打包，然后观察打包结果中最终生成的内容是否为

Maven 中配置的内容。

上面的属性管理就已经完成，但是有一个问题没有解决，因为不只是 maven_02_ssm 项目需要有属性被父工程管理，如果有多个项目需要配置，该如何实现呢 ?

方式一:

方式二:

说明:打包的过程中如果报如下错误:

原因就是 Maven 发现你的项目为 web 项目，就会去找 web 项目的入口 web.xml[ 配置文件配置的方

式 ] ，发现没有找到，就会报错。

解决方案 1 ：在 maven_02_ssm 项目的 src\main\webapp\WEB - INF\ 添加一个 web.xml 文件

解决方案2: 配置maven打包war时，忽略web.xml检查

具体如何查看这些属性 :

在 cmd命令行中输入mvn help:system

具体使用，就是使用 ${key} 来获取， key 为等号左边的，值为等号右边的，比如获取红线的值，对

应的写法为 ${java.runtime.name}

4.3 版本管理

关于这个版本管理解决的问题是，在 Maven 创建项目和引用别人项目的时候，我们都看到过如下内容 :

在我们 jar 包的版本定义中，有两个工程版本用的比较多 :

SNAPSHOT（快照版本）

项目开发过程中临时输出的版本，称为快照版本

快照版本会随着开发的进展不断更新

RELEASE（发布版本）

项目开发到一定阶段里程碑后，向团队外部发布较为稳定的版本，这种版本所对应的构件文件

是稳定的

即便进行功能的后续开发，也不会改变当前发布版本内容，这种版本称为发布版本

除了上面的工程版本，我们还经常能看到一些发布版本 :

alpha版: 内测版， bug 多不稳定内部版本不断添加新功能

beta版: 公测版，不稳定 ( 比 alpha 稳定些 ) ， bug 相对较多不断添加新功能

纯数字版

5，多环境配置与应用

5.1 多环境开发

maven 提供配置多种环境的设定，帮助开发者在使用过程中快速切换环境。具体实现步骤 :

步骤 1: 父工程配置多个环境 , 并指定默认激活环境

    <!--配置多环境-->
    <profiles>
        <!--开发环境-->
        <profile>
            <id>env_dep</id>
            <properties>
                <jdbc.url>jdbc:mysql://127.1.1.1:3306/ssm_db</jdbc.url>
            </properties>
            <!--设定是否为默认启动环境-->
            <activation>
                <activeByDefault>true</activeByDefault>
            </activation>
        </profile>
        <!--生产环境-->
        <profile>
            <id>env_pro</id>
            <properties>
                <jdbc.url>jdbc:mysql://127.2.2.2:3306/ssm_db</jdbc.url>
            </properties>
        </profile>
        <!--测试环境-->
        <profile>
            <id>env_test</id>
            <properties>
                <jdbc.url>jdbc:mysql://127.3.3.3:3306/ssm_db</jdbc.url>
            </properties>
        </profile>
    </profiles>

步骤 2: 执行安装查看 env_dep 环境是否生效

步骤3:切换默认环境为生产环境

在activation属性中activeByDefault设置为true

步骤 4: 执行安装并查看env_pro环境是否生效

步骤5:命令行实现环境切换

步骤 6: 执行安装并查看env_test环境是否生效

5.2 跳过测试

方式一 :IDEA 工具实现跳过测试

图中的按钮为 Toggle 'Skip Tests' Mode ,

Toggle 翻译为切换的意思，也就是说在测试与不测试之间进行切换。

方式二 : 配置插件实现跳过测试

在父工程中的 pom.xml 中添加测试插件配置

    <build>
        <plugins>
            <plugin>
                <artifactId>maven-surefire-plugin</artifactId>
                <version>2.12.4</version>
                <configuration>
                    <skipTests>false</skipTests>
                    <!--排除掉不参与测试的内容-->
                    <excludes>
                        <exclude>**/BookServiceTest.java</exclude>
                    </excludes>
                </configuration>
            </plugin>
        </plugins>
    </build>

skipTests: 如果为 true ，则跳过所有测试，如果为 false ，则不跳过测试

excludes ：哪些测试类不参与测试，即排除，针对 skipTests 为 false 来设置的

includes: 哪些测试类要参与测试，即包含 , 针对 skipTests 为 true 来设置的

方式三:命令行跳过测试

使用 Maven 的命令行， mvn 指令 - D skipTests

注意事项 :

执行的项目构建指令必须包含测试生命周期，否则无效果。例如执行 compile 生命周期，不经过

test 生命周期。

该命令可以不借助 IDEA ，直接使用 cmd 命令行进行跳过测试，需要注意的是 cmd 要在 pom.xml 所在

目录下进行执行。

6，私服

6.1 私服简介

私服:公司内部搭建的用于存储Maven资源的服务器

远程仓库:Maven开发团队维护的用于存储Maven资源的服务器

所以说 :私服是一台独立的服务器，用于解决团队内部的资源共享与资源同步问题

6.2 私服安装

步骤 1: 下载解压

将资料 \latest - win64.zip 解压到一个空目录下。

步骤 2:启动Nexus

使用cmd进入到解压目录下的nexus-3.30.1-01\bin ,执行如下命令: nexus.exe /run nexus

看到如下内容，说明启动成功

步骤 3: 浏览器访问

访问地址为 :http://localhost:8081

步骤 4: 首次登录重置密码

输入用户名和密码进行登录，登录成功后，出现如下页面

点击下一步，需要重新输入新密码，为了和后面的保持一致，密码修改为admin

设置是否运行匿名访问

点击完成

至此私服就已经安装成功。如果要想修改一些基础配置信息，可以使用:

修改基础配置信息

安装路径下 etc 目录中 nexus-default.properties 文件保存有 nexus 基础配置信息，例如

默认访问端口。

修改服务器运行配置信息

安装路径下 bin 目录中 nexus.vmoptions 文件保存有 nexus 服务器启动对应的配置信息，例如

默认占用内存空间。

6.3 私服仓库分类

私服资源操作流程分析 :

(1) 在没有私服的情况下，我们自己创建的服务都是安装在 Maven 的本地仓库中

(2) 私服中也有仓库，我们要把自己的资源上传到私服，最终也是放在私服的仓库中

(3) 其他人要想使用你所上传的资源，就需要从私服的仓库中获取

(4) 当我们要使用的资源不是自己写的，是远程中央仓库有的第三方 jar 包，这个时候就需要从远程中央仓库下载，每个开发者都去远程中央仓库下速度比较慢 ( 中央仓库服务器在国外 )

(5) 私服就再准备一个仓库，用来专门存储从远程中央仓库下载的第三方 jar 包，第一次访问没有就会去远程中央仓库下载，下次再访问就直接走私服下载

(6) 前面在介绍版本管理的时候提到过有 SNAPSHOT 和 RELEASE ，如果把这两类的都放到同一个仓库，比较混乱，所以私服就把这两个种 jar 包放入不同的仓库

(7) 上面我们已经介绍了有三种仓库，一种是存放 SNAPSHOT 的，一种是存放 RELEASE 还有一种是存放从远程仓库下载的第三方 jar 包，那么我们在获取资源的时候要从哪个仓库种获取呢 ?

(8) 为了方便获取，我们将所有的仓库编成一个组，我们只需要访问仓库组去获取资源。

所有私服仓库总共分为三大类 :

宿主仓库hosted

保存无法从中央仓库获取的资源

自主研发

第三方非开源项目 , 比如 Oracle, 因为是付费产品，所以中央仓库没有

代理仓库proxy

代理远程仓库，通过 nexus 访问其他公共仓库，例如中央仓库

仓库组group

将若干个仓库组成一个群组，简化配置

仓库组不能保存资源，属于设计型仓库

6.4 本地仓库访问私服配置

我们通过 IDEA 将开发的模块上传到私服，中间是要经过本地 Maven 的

本地 Maven 需要知道私服的访问地址以及私服访问的用户名和密码

私服中的仓库很多， Maven 最终要把资源上传到哪个仓库 ?

Maven 下载的时候，又需要携带用户名和密码到私服上找对应的仓库组进行下载，然后再给 IDEA

上面所说的这些内容，我们需要在本地 Maven 的配置文件 settings.xml 中进行配置。

步骤1:私服上配置仓库

说明 :

第 5 ， 6 步骤是创建 itheima-snapshot 仓库

第 7 ， 8 步骤是创建 itheima-release 仓库

步骤 2: 配置本地 Maven 对私服的访问权限

本地 Maven 的配置文件 settings.xml 中进行配置。

步骤3:配置私服的访问路径

为了避免阿里云 Maven 私服地址的影响，建议先将之前配置的阿里云 Maven 私服镜像地址注释掉，等练习完后，再将其恢复。

6.5 私服资源上传与下载

本地仓库与私服已经建立了连接，接下来我们就需要往私服上上传资源和下载资源，具体的实现步骤为 :

    <!--配置当前工程保存在私服中的具体位置-->
    <distributionManagement>
        <repository>
            <id>itheima-release</id>
            <url>http://localhost:8081/repository/itheima-release/</url>
        </repository>
        <snapshotRepository>
            <id>itheima-snapshot</id>
            <url>http://localhost:8081/repository/itheima-snapshot/</url>
        </snapshotRepository>
    </distributionManagement>

步骤2:发布资源到私服

注意 :

要发布的项目都需要配置 distributionManagement 标签，要么在自己的 pom.xml 中配置，要么在其

父项目中配置，然后子项目中继承父项目即可。

发布成功，在私服中就能看到：

现在发布是在 itheima-snapshot 仓库中，如果想发布到 itheima-release 仓库中就需要将项目

pom.xml 中的 version 修改成 RELEASE 即可。

如果想删除已经上传的资源，可以在界面上进行删除操作:

如果私服中没有对应的jar，会去中央仓库下载，速度很慢。可以配置让私服去阿里云中下载依赖。

小夫敲代码

关注

3
点赞
踩
3

收藏

觉得还不错? 一键收藏
0
评论
Spring---Maven高级

将抽取后的项目进行运行，测试之前的增删改查功能依然能够使用。所以对于项目的拆分，大致会有如下几个步骤:(1)创建Maven模块(2)书写模块代码分模块开发需要先针对模块功能进行设计，再进行编码。不会先将工程开发完毕，然后进行拆分。拆分方式可以按照功能拆也可以按照模块拆。(3)通过maven指令安装模块到本地仓库(install指令)团队内部开发需要发布模块功能到团队内部可共享的仓库中(私服)，私服我们后面会讲解。
复制链接

扫一扫

专栏目录