java回顾：Maven高级

我迪迦在东北啊

已于 2022-12-20 16:28:53 修改

阅读量732

点赞数 2

分类专栏： java回顾文章标签： maven java

于 2022-12-20 16:28:05 首次发布

本文链接：https://blog.csdn.net/m0_56678122/article/details/128384527

版权

java回顾专栏收录该内容

40 篇文章 0 订阅

订阅专栏

一、私服搭建

https://blog.csdn.net/m0_56678122/article/details/128382822

二、Maven高级

2.1、依赖范围

对于servlet依赖必须加provide，因为运行时tomcat自身包含servlet，会冲突报错。

环境：
测试环境：test包下的代码
编译环境：书写java代码的环境。
运行环境：war+tomcat环境

依赖范围：
provide:作用于编译时和测试时，不做用于运行时。例如servlet。因为tomcat已经提供了。
runtime: 作用于运行时和测试时，但是不作用于编译时。例如mysql驱动。
test:只需要作用于测试时。例如junit
compile:默认值，作用于运行时，编译时，测试时。

绝大多数情况，依赖范围用的不好，只是造成资源的浪费，并不会有其他影响。
但是对于servlet的依赖范围，provide是必须要添加的，要不然会报错。

        <dependency>
            <groupId>junit</groupId>
            <artifactId>junit</artifactId>
            <version>4.12</version>
            <!--如加入test范围，那么只能在test环境包下使用@Test注解，
            且打包后lib文件夹中也不会有test相关文件-->
            <scope>test</scope>
        </dependency>
        <dependency>
            <groupId>javax.servlet</groupId>
            <artifactId>javax.servlet-api</artifactId>
            <version>3.0.1</version>
            <!--必须要加provided因为运行时tomcat自身包含servlet，会冲突，
            打成war包后lib文件夹下有servlet的jar包-->
            <scope>provided</scope>
        </dependency>

2.2、依赖传递

依赖传递：
如果A依赖于B,当引入依赖A的时候，maven会自动的引入A所依赖的B.

例如：
spring-context 依赖于spring-core等等。
所以我们引入spring-context，会自动的引入spring-core。

创建2个工程demo_01和demo_02,
demo_01依赖其他的jar包
demo_02依赖于demo_01.所以，根据传递依赖，demo_02也会依赖于其他jar包

2.3、依赖可选

A依赖于B,当我们引入A的时候，maven会自动的引入A所依赖的B。
对于我们来说，不一定需要B。所以如何解决。
1.依赖可选，A在引入B的时候，添加声明，B依赖是可选的。其他工程引入A的时候，就不会引入B了。
2.依赖排除，工程在引入A的时候，添加声明，不需要B依赖。所以就不会引入B依赖。

测试：

1.创建工程Demo_A,引入依赖Junit,配置依赖可选
2.创建工程Demo_B,引入工程Demo_A. 根据依赖传递，Demo_B应该自动的引入Junit.

不设置依赖可选：

设置依赖可选：

2.4、依赖排除

Demo_A工程直接引入junit，
Demo_B工程引入依赖Demo_A,Demo_B在引入Demo_A的时候，声明需要排除的依赖。

2.5、依赖冲突

maven默认结觉办法：

Demo_A,Demo_B,Demo_C
Demo_A引入spring-context(5.0.6),依赖传递spring-core
Demo_B引入spring-core(4.1.2),
Demo_C引入Demo_A和Demo_B,Demo_C同时依赖spring-core的2个版本，版本冲突。

maven解决版本冲突的原则：
1.路径最短者优先。
2.路径相同，先声明者优先。

路径最短者优先演示：（ctrl+alt+u）查看maven的依赖路径

路径相同先声明者优先 先声明就是先一步引入依赖

将Demo_A的依赖切换成spring-core的5.0.6的版本

三、ssm工程改造成分层构建

maven的继承和聚合是2个不一样的概念。

3.1、maven的继承

maven的继承：
1.用于抽取公共配置
2.方便所有子工程的依赖版本的统一维护
3.父工程中，没有java代码。

父工程自动打pom包（也必须打pom包）

步骤：
1.创建父工程Demo_parent,删除src文件夹，右键项目创建model（子工程）

此时父工程自动打pom包（也必须打pom包）
2.创建子工程Demo_child_A，此时自动通过标签声明父工程
3.父工程引入依赖，子工程继承

3.2、继承的一些应用

父工程中：
1.针对于所有子工程需要的依赖，才去<dependencies>中声明，方便所有子工程的继承。
2.非所有子工程需要的依赖，在<dependencyManagement>声明，只会锁定版本，不会真的引入
哪个子工程需要，再次编写坐标（不包含version）配置引入
3.所有依赖的版本统一在<properties>中声明。
4.插件也是上述管理操作

<?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.hhy</groupId>
    <artifactId>maven_parent</artifactId>
    <!-- 父工程必须打pom包 -->
    <packaging>pom</packaging>
    <version>1.0-SNAPSHOT</version>
    <!-- 声明子模块-->
    <modules>
        <module>maven_child1</module>
        <module>maven_child_user</module>
    </modules>

    <!--
        maven中继承的实际应用：

        强调：
            1.maven的继承是用来抽取公共的配置的
            2.父工程中没有java代码，只有一个pom.xml
        继承的实际使用细节：
        1.<dependencies>中，只会声明一些所有子工程都需要的依赖，例如：junit,或者一些其他工具包
        2.对于非所有子模块需要的依赖，我们统一声明到<dependencyManagement>标签中，
            用来锁定版本，然后子工程要用，再去引入即可。
        3.针对于所有的依赖，或者插件，或者模块的版本号，我们统一的在<properties>中进行声明，统一管理。
    -->
    <dependencies>
        <dependency>
            <groupId>junit</groupId>
            <artifactId>junit</artifactId>
            <version>${junit.version}</version>
        </dependency>
    </dependencies>

    <!-- 依赖管理，只是用来锁定依赖的版本的，不会真的去引入依赖。一般都是用在父工程中的-->
    <dependencyManagement>
        <dependencies>
            <dependency>
                <groupId>mysql</groupId>
                <artifactId>mysql-connector-java</artifactId>
                <version>${mysql.version}</version>
            </dependency>
        </dependencies>
    </dependencyManagement>


    <properties>
        <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
        <!-- 依赖版本的统一管理-->
        <mysql.version>5.1.38</mysql.version>
        <junit.version>4.12</junit.version>
    </properties>
    <build>
        <plugins>
            <!-- java编译插件 -->
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-compiler-plugin</artifactId>
                <version>3.2</version>
                <configuration>
                    <source>1.8</source>
                    <target>1.8</target>
                </configuration>
            </plugin>
            <!-- tomcat7插件,命令： mvn tomcat7:run -DskipTests -->
            <plugin>
                <groupId>org.apache.tomcat.maven</groupId>
                <artifactId>tomcat7-maven-plugin</artifactId>
                <version>2.2</version>
                <configuration>
                    <uriEncoding>utf-8</uriEncoding>
                    <port>8080</port>
                    <path>/</path>
                </configuration>
            </plugin>
        </plugins>
    </build>
</project>

子工程配置：

子工程需要哪些模块，再次配置，但不需声明版本，由父工程统一管理。

3.3、maven的聚合（多模块开发）

maven的聚合：多模块开发。
当工程比较庞大的时候，此时一个开发者负责一个模块。
而之前的工程，所有的代码全部放在一起。此时也就意味着哪怕负责单个模块，
也需要将所有的代码拉取到本地。而且如果不小心动了其他模块的代码呢。
所以在针对于上述这些情况，针对工程进行分模块构建，
例如：用户模块单独做成一个工程，订单模块单独做成一个工程，
	A组负责用户模块的开发
	B组负责订单模块的开发。
好处：
1.方便企业开发的分工合作
2.方便分布式项目的管理

说白了：maven的聚合就是将一个工程，拆分成多个工程进行管理。
如何拆分：
1.纵向拆分：
	按照项目的层次结构进行拆分。service层作为一个模块，dao层作为一个模块。	
2.横向拆分：
	按照功能模块进行拆分，用户模块，订单模块，物流模块，支付模块

上述继承时，已经使用了聚合了。

父工程中自动添加了子模块的声明：