Maven高级

(1)按照功能拆分：将原始模块按照功能拆分成若干个子模块，方便模块间的相互调用，接口共享。避免单模块代码的异常导致整个项目无法正常运行

我们现在的项目都是在一个模块中，比如前面的SSM整合开发。虽然这样做功能也都实现了，但是也存在了一些问题，我们拿银行的项目为例：银行柜台或者取款机进行业务操作、在网页上登录银行网站使用U盾进行业务操作、用手机登录APP就可以进行业务操作，如果非要把三个场景的模块代码放入到一个项目，那么当其中某一个模块代码出现问题，就会导致整个项目无法正常启动，从而导致银行的多个业务都无法正常班理。所以我们会按照功能将项目进行拆分。

(2)按照模块拆分：多模块中具有重复的模型类，提取公共部分为单独模块，其他模块通过导入的方式使用，避免代码重复

比如电商的项目中，有订单和商品两个模块，订单中需要包含商品的详细信息，所以需要商品的模型类，商品模块也会用到商品的模型类，这个时候如果两个模块中都写模型类，就会出现重复代码，后期的维护成本就比较高。我们就想能不能将它们公共的部分抽取成一个独立的模块，其他模块要想使用可以像添加第三方jar包依赖一样来使用我们自己抽取的模块，这样就解决了代码重复的问题,这种拆分方式就说我们所说的按照模块拆分。

刚刚我们说了可以将domain层进行拆分，除了domain层，我们也可以将其他的层也拆成一个个对立的模块，项目中的每一层都可以单独维护，也可以很方便的被别人使用。如:

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

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

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

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

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

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

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

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

    com.itheima
    maven_03_pojo
    1.0-SNAPSHOT

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

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

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

为什么找不到呢?

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

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

将需要被依赖的项目maven_03_pojo，使用maven的install命令，把其安装到Maven的本地仓库中。
安装成功后，在对应的路径下就看到安装好的jar包

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

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

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

在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项目

    
        
            com.itheima
            maven_03_pojo
            1.0-SNAPSHOT
        
    
    

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

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

    
        
            org.mybatis
            mybatis
            3.5.6
        
    
        
            mysql
            mysql-connector-java
            5.1.47
        
    
    

删除Dao包以后，因为maven_02_ssm中的BookServiceImpl类中有使用到Dao的内容，所以需要在maven_02_ssm的pom.xml添加maven_04_dao的依赖

    com.itheima
    maven_04_dao
    1.0-SNAPSHOT

此时在maven_02_ssm项目中就已经添加了maven_03_pojo和maven_04_dao包
同样将maven_04_dao安装到Maven的本地仓库，再次对maven_02_ssm项目进行compile编译即可。

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

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

(1) 创建Maven模块

(2) 书写模块代码：先针对模块功能进行设计，再进行编码（不是先开发再拆分）

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

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

我们现在已经能把项目拆分成一个个独立的模块，当在其他项目中想要使用独立出来的这些模块，只需要在其pom.xml使用标签来进行jar包的引入即可。

其实就是依赖，关于依赖管理的内容，我们就一个个来学习下:

• 依赖传递
• 可选依赖
• 排除依赖

我们先来说说什么是依赖:

依赖指当前项目运行所需的jar，一个项目可以设置多个依赖。

格式为:

    
    
        
        org.springframework
        
        spring-webmvc
        
        5.2.10.RELEASE
    

回到我们刚才的项目案例中，打开Maven的面板，你会发现:
在项目所依赖的这些jar包中，有一个比较大的区别就是有的依赖前面有箭头>,有的依赖前面没有。

那么这个箭头所代表的含义是什么?
打开前面的箭头，你会发现这个jar包下面还包含有其他的jar包

依赖传递：依赖是具有传递性的

**说明:**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，展示出jar包之间的相互依赖关系。

依赖传递介绍完以后，我们来思考一个问题，

• maven_02_ssm 依赖了 maven_04_dao，maven_04_dao 依赖了 maven_03_pojo， 因为现在有依赖传递，所以maven_02_ssm能够使用到maven_03_pojo的内容
• 如果说现在不想让maven_02_ssm依赖到maven_03_pojo（实际是需要的），有哪些解决方案?
  即：
• A依赖B,B依赖C,C通过依赖传递会被A使用到，现在要想办法让A不去依赖C
• 可选依赖是在B上设置,A不知道有C的存在，
• 排除依赖是在A上设置,A知道有C的存在，主动将其排除掉。

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

    com.itheima
    maven_03_pojo
    1.0-SNAPSHOT
    
    true

可选依赖实现了阻断maven_03_pojo的依赖传递

排除依赖，则指的是已经有依赖的事实，也就是说maven_02_ssm项目中已经通过依赖传递用到了maven_03_pojo，此时我们需要做的是将其进行排除，所以接下来需要修改maven_02_ssm的pom.xml

    com.itheima
    maven_04_dao
    1.0-SNAPSHOT
    
    
        
            com.itheima
            maven_03_pojo
        
    

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

项目一旦变成了多模块开发以后，就会引发一些问题，在这一节中我们主要会学习两个内容聚合和继承，用这两个知识来解决下分模块后的一些问题。

存在的问题:

• 分模块开发后，需要将这四个项目都安装到本地仓库，目前我们只能通过项目Maven面板的install来安装，并且需要安装四个，如果我们的项目足够多，那么一个个安装起来还是比较麻烦的
• 如果四个项目都已经安装成功，当ssm_pojo发生变化后，我们就得将ssm_pojo重新安装到maven仓库，但是为了确保我们对ssm_pojo的修改不会影响到其他项目模块，我们需要对所有的模块进行重新编译，那又需要将所有的模块再来一遍
• 如果项目多的话，一个个操作项目就容易出现漏掉或重复操作的问题，

解决思路：能不能抽取一个项目，把所有的项目管理起来，以后我们要想操作这些项目，只需要操作这一个项目，其他所有的项目都走一样的流程，这个不就很省事省力。即：聚合

• 聚合:将多个模块组织成一个整体，同时进行项目构建的过程称为聚合
• 聚合工程：通常是一个不具有业务功能的"空"工程（有且仅有一个pom文件）
• 作用：使用聚合工程可以将多个工程编组，通过对聚合工程进行构建，实现对所包含的模块进行同步构建
  • 当工程中某个模块发生更新（变更）时，必须保障工程中与已更新模块关联的模块同步更新，此时可以使用聚合工程来解决批量模块同步构建的问题。
  • 聚合工程主要是用来管理项目。

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

    4.0.0

    com.itheima
    maven_01_parent
    1.0-RELEASE
    pom
    

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

• jar:默认情况，说明该项目为java项目
• war:说明该项目为web项目
• pom:说明该项目为聚合或继承(后面会讲)项目

    4.0.0

    com.itheima
    maven_01_parent
    1.0-RELEASE
    pom
    
    
    
        ../maven_02_ssm
        ../maven_03_pojo
        ../maven_04_dao
    

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

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

父工程主要是用来快速配置依赖jar包和管理项目中所使用的资源。

存在的问题 ：多模块开发存在的另外一个问题，重复配置的问题，（依赖具有传递性，模块配置中的依赖重复）我们先来看张图:

• spring-webmvc、spring-jdbc在三个项目模块中都有出现，这样就出现了重复的内容：继承父工程
• spring-test只在ssm_crm和ssm_goods中出现，而在ssm_order中没有，这里是部分重复的内容：父工程中配置可选依赖
• 我们使用的spring版本目前是5.2.10.RELEASE,假如后期要想升级spring版本，所有跟Spring相关jar包都得被修改，涉及到的项目越多，维护成本越高

解决思路：继承

• 继承:描述的是两个工程间的关系，与java中的继承相似，子工程可以继承父工程中的配置信息，常见于依赖关系的继承。
• 作用：
  • 简化配置
    • 将所有项目公共的jar包依赖提取到父工程的pom.xml中，子项目就可以不用重复编写，简化开发
  • 减少版本冲突
    • 将所有项目的jar包配置到父工程的dependencyManagement标签下，实现版本管理，方便维护
    • dependencyManagement标签不真正引入jar包，只是管理jar包的版本，管理可选依赖
    • 子项目在引入的时候，只需要指定groupId和artifactId，不需要加version
    • 当dependencyManagement标签中jar包版本发生变化，所有子项目中有用到该jar包的地方对应的版本会自动随之更新

接下来，我们到程序中去看看继承该如何实现?

实际开发中，聚合和继承一般也都放在同一个项目中，但是这两个的功能是不一样的。

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

    com.itheima
    maven_01_parent
    1.0-RELEASE
    
    ../maven_01_parent/pom.xml

将子项目共同使用的jar包都抽取出来，维护在父项目的pom.xml中，并删除子项目中已经被抽取到父项目的pom.xml中的jar包

    4.0.0

    com.itheima
    maven_01_parent
    1.0-RELEASE
    pom
    
    
    
        ../maven_02_ssm
        ../maven_03_pojo
        ../maven_04_dao
    
    
        
            org.springframework
            spring-core
            5.2.10.RELEASE
        

        
            org.springframework
            spring-webmvc
            5.2.10.RELEASE
        

        
            org.springframework
            spring-jdbc
            5.2.10.RELEASE
        

        
            org.springframework
            spring-test
            5.2.10.RELEASE
        

        
            org.mybatis
            mybatis
            3.5.6
        

        
            org.mybatis
            mybatis-spring
            1.3.0
        

        
            mysql
            mysql-connector-java
            5.1.47
        

        
            com.alibaba
            druid
            1.1.16
        

        
            javax.servlet
            javax.servlet-api
            3.1.0
            provided
        

        
            com.fasterxml.jackson.core
            jackson-databind
            2.9.0
        
    

• 删除完后，你会发现父项目中有依赖对应的jar包，子项目虽然已经将重复的依赖删除掉了，但是刷新的时候，子项目中所需要的jar包依然存在。
• 将子项目中的公共jar包抽取到父工程中进行统一添加依赖，这样做的可以简化配置，并且当父工程中所依赖的jar包版本发生变化，所有子项目中对应的jar包版本也会跟着更新。
• 当项目的标签被移除掉，会发现多出来的jar包依赖也会随之消失。

如果把所有用到的jar包都管理在父项目的pom.xml，看上去更简单些，但是这样就会导致有很多项目引入了过多自己不需要的jar包。

如果把所有的依赖都放在了父工程中进行统一维护，就会导致ssm_order项目中多引入了spring-test的jar包，如果这样的jar包过多的话，对于ssm_order来说也是一种"负担"。

那针对于这种部分项目有的jar包，我们该如何管理优化呢?

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

    
        
            junit
            junit
            4.12
            test
        
    

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

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

标签不真正引入jar包，而是配置可供子项目选择的jar包依赖，子项目要想使用它所提供的这些jar包，需要自己添加依赖，并且不需要指定

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

    junit
    junit
    test

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

这个时候，maven_02_ssm和maven_04_dao这两个项目中的junit版本就会跟随着父项目中的标签dependencyManagement中junit的版本发生变化而变化。不需要junit的项目就不需要添加对应的依赖即可。

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

  pom
  

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

  
      
          org.springframework
          spring-webmvc
          5.2.10.RELEASE
      
      ...
  
  

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

  
      
          
              com.alibaba
              druid
              1.1.16
          
      
      ...
  
  

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

  
  
      com.itheima
      maven_01_parent
      1.0-RELEASE
      
      ../maven_01_parent/pom.xml
  
  

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

  
      
          com.alibaba
          druid
      
  
  

  注意事项:

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

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

两种之间的作用:

• 聚合用于快速构建项目，对项目进行管理
• 继承用于快速配置和管理子项目中所使用jar包的版本

聚合和继承的相同点:

• 聚合与继承的pom.xml文件打包方式均为pom，可以将两种关系制作到同一个pom文件中
• 聚合与继承均属于设计型模块，并无实际的模块内容

聚合和继承的不同点:

• 聚合是在当前模块中配置关系，聚合可以感知到参与聚合的模块有哪些
• 继承是在子模块中配置关系，父模块无法感知哪些子模块继承了自己

在聚合和继承的工程构建时，需要在聚合项目中手动添加modules标签，需要在所有的子项目中添加parent标签，手动添加标签容易出错怎么办？如何自动生成

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

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

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

创建成功后，maven_parent即是聚合工程又是父工程，maven_web中也有parent标签，继承的就是maven_parent,对于难以配置的内容都自动生成。

在这一章节内容中，我们将学习两个内容，分别是

• 属性
• 版本管理

属性中会继续解决分模块开发项目存在的问题，版本管理主要是认识下当前主流的版本定义方式。

存在的问题：

前面我们已经在父工程中的dependencyManagement标签中对项目中所使用的jar包版本进行了统一的管理，但是如果在标签中存在多个相同Spring版本号，如下图:

更新Spring的版本就会很麻烦，更改时容易出现遗漏，如何统一配置？

解决思路：在父工程声明一个变量，在其他地方使用该变量，当变量的值发生变化后，所有使用变量的地方，就会跟着修改。

    5.2.10.RELEASE
    4.12
    1.3.0

    org.springframework
    spring-core
    ${spring.version}


    org.springframework
    spring-webmvc
    ${spring.version}


    org.springframework
    spring-jdbc
    ${spring.version}

更新父工程中properties标签中所维护的jar包版本，所有子项目中的版本也就跟着更新。实现对项目中所有jar包的版本进行统一维护

通过Maven来集中管理Maven中依赖jar包的版本。
Maven对于属性的管理范围能更大些，比如我们之前项目中的jdbc.properties，这个配置文件中的属性，能不能也来让Maven进行管理呢?

答案是肯定的，具体的实现步骤为:

   jdbc:mysql://127.1.1.1:3306/ssm_db

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

jdbc.driver=com.mysql.jdbc.Driver
jdbc.url=${jdbc.url}
jdbc.username=root
jdbc.password=root

Maven在默认情况下是从当前项目的srcmainresources下读取文件进行打包。现在我们需要打包的资源文件是在maven_02_ssm下,需要我们通过配置来指定下具体的资源目录。

    
        
        
            ../maven_02_ssm/src/main/resources
            
            true
        
    

**说明:**directory路径前要添加../的原因是maven_02_ssm相对于父工程的pom.xml路径是在其上一层的目录中，所以需要添加。

修改完后，注意maven_02_ssm项目的resources目录就多了该配置文件，如下:

方式一:配置多个资源目录，并设置能够解析${} （繁琐）

    
        
        
            ../maven_02_ssm/src/main/resources
            true
        
        
            ../maven_03_pojo/src/main/resources
            true
        
        ...
    

可以配，但是如果项目够多的话，这个配置也是比较繁琐

方式二: ${project.basedir}表示当前项目所在目录

    
        
        
            ${project.basedir}/src/main/resources
            true
        
    

并且在配置maven打包war时，忽略web.xml检查

    
        
            org.apache.maven.plugins
            maven-war-plugin
            3.2.3
            
                false
            
        
    

上面我们所使用的都是Maven的自定义属性，除了${project.basedir},它属于Maven的内置系统属性。

在Maven中的属性分为:

• 自定义属性（常用）
• 内置属性
• Setting属性
• Java系统属性
• 环境变量属性
  

具体如何查看这些属性:
在cmd命令行中输入mvn help:system

具体使用，就是使用 ${key}来获取，key为等号左边的，值为等号右边的，比如获取属性值，对应的写法为 ${java.runtime.name}。

版本管理中有两个单词，SNAPSHOT和RELEASE，它们所代表的含义是什么呢?

• SNAPSHOT（快照版本）
  • 项目开发过程中临时输出的版本，称为快照版本
  • 快照版本会随着开发的进展不断更新
• RELEASE（发布版本）
  • 项目开发到一定阶段里程碑后，向团队外部发布较为稳定的版本，这种版本所对应的构件文件是稳定的
  • 即便进行功能的后续开发，也不会改变当前发布版本内容，这种版本称为发布版本

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

• alpha版:内测版，bug多不稳定内部版本不断添加新功能
• beta版:公测版，不稳定(比alpha稳定些)，bug相对较多不断添加新功能
• 纯数字版

对于这些版本，大家只需要简单认识下即可。

    
    
        env_dep
        
            jdbc:mysql://127.1.1.1:3306/ssm_db
        
        
        
            true
        
    
    
    
        env_pro
        
            jdbc:mysql://127.2.2.2:3306/ssm_db
        
    
    
    
        env_test
        
            jdbc:mysql://127.3.3.3:3306/ssm_db
        
    

    
    
        env_dep
        
            jdbc:mysql://127.1.1.1:3306/ssm_db
        
    
    
    
        env_pro
        
            jdbc:mysql://127.2.2.2:3306/ssm_db
        
        
        
            true
        
    
    
    
        env_test
        
            jdbc:mysql://127.3.3.3:3306/ssm_db
        
    

    
        
            maven-surefire-plugin
            2.12.4
            
                false
                
                
                    **/BookServiceTest.java
                
            
        
    

nexus.exe /run nexus

    
        itheima-snapshot
        admin
        admin
    
    
        itheima-release
        admin
        admin
    

    
        
        maven-public
        
        *
        
        http://localhost:8081/repository/maven-public/
    

 

    
        
        itheima-release
         
        http://localhost:8081/repository/itheima-release/
    
    
        
        itheima-snapshot
        
        http://localhost:8081/repository/itheima-snapshot/