学习maven（添加依赖坐标，maven的常用命令，依赖传递，解决依赖冲突）

前言

添加依赖坐标

[maven 的常用命令](#maven 的常用命令)

如下图所示：重点是标红的

如何使用这些maven的常用命令呢？

实例

maven常用的命令可以在IDEA中有自带插件来完成

前言

本篇博客的重点

学会从maven中央仓库中下载jar 包，或复制依赖坐标
学会使用 maven常用命令
理解依赖传递和处理如何解决冲突问题

添加依赖坐标

之前，我们需要的jar包，都是从别人的网盘中获取，或从对应的官网中下载 。现在我提供一个maven 中央仓库的网址。

作用:是帮助我们快速找到我们需要的jar包或添加的依赖

网址：https://mvnrepository.com/

当你将这个网址复制到浏览器，访问后，首先会出现一个判断你是否为人机的界面

你的操作是，在一个验证是否为人机的框中选中即可。等待下一步跳转到主界面

如下图所示：

操作步骤

1 打开官网主界面

2 搜索框中搜索我们需要的jar包名字

我现在假设我需要一个servlet jar包。

我的操作是：从搜索框中搜索jar包的名字

3 找到点击量最高的那个，点击你需要的jar包名字

3.1 点击你需要的jar包名字

3.2 选择合适的版本【一般选择使用量最高的那个】

点击版本号到下一步

4选择构建方式【一般是选择maven 构建的】

选择好合适的版本后，看你选择的方式：下载jar包/ 添加依赖坐标

4.1根据自己的需求，选择下载jar包，还是在向pom文件中添加依赖坐标

点击下载jar包：出现一个下载jar的,等待下载

点击我框中的依赖，就已经复制好了，就到我们的通过maven 构建的项目的pom文件中添加这些依赖坐标。

本次博客中，我重点讲的是如何在pom文件中添加你需要用的依赖坐标、

从上面将，我们的需要的依赖坐标，也从maven中央仓库中找到了，现在我们就将依赖复制到pom文件中，但我们应该放到哪一个位置呢?

我们是使用这个标签<dependencies> </dependencies> 将我们复制的内容包起来，之后再刷新一下，等待从中央仓库下载到你的本地仓库中去

maven 的常用命令

如下图所示：重点是标红的

mvn clean：调用clean生命周期的clean阶段，清理上一次构建项目生成的文件；
mvn compile ：编译src/main/java中的java代码；
mvn test ：编译并运行了test中内容；
mvn package：将项目打包成可发布的文件，如jar或者war包；
mvn install ：发布项目到本地仓库；

如何使用这些maven的常用命令呢？

实例

题目：我需要把当前web项目打包成war 包

注意：我们是根据项目类型，选择打包方式：

如果你是Java项目自动打包成jar 包
如果你是 web项目自动打包成 war包

这里有两种方式实现

IDEA自带的插件来完成
打开终端来完成

maven常用的命令可以在IDEA中有自带插件来完成

步骤

1 打开IDEA 在maven 构建的项目中可以看到右边的maven 标志，点击找到 maven的生命周期 ,点击就可以看到

2 鼠标点击右上角maven的生命周期找到package ,点击它，就执行这个任务

你需要哪一个就点击哪一个，你点击这个插件本质和在终端使用 mvn package 是一样的

打开IDEA的命令行终端

通过输入命令的方式，根据项目类型打包成 jar包/war包

输入命令： mvn package

成功的标志是

依赖传递

什么是依赖传递呢？

举一个例子：创建一个项目A 我引入两个给依赖 B jar包, C jar 包，其中依赖B,C 内部均依赖了 D ja包

那么我可以说：项目A直接依赖B，C 间接依赖 D。这就是所谓的 " 依赖传递"

解决依赖冲突问题

什么是依赖冲突问题？

就上面我举得例子，引入的两个jar 包内部都使用 D jar 包，但使用D jar包的版本却都不相同。

那应该选择哪一个版本的Djar包？这就是依赖冲突问题。

IDEA 面对这个问题，有可能会报错

解决依赖冲突

有三种办法

1 使用maven提供的依赖调解原则 (自动)

第一种方式，不用我们修改什么，我们通过maven 构建的项目会自动修复，舍弃其中一个。

根据以下两个舍弃原则：

1.1 依赖传递jar包,第一声明者优先原则

在pom.xml文件中,先声明哪个jar包,就以那个jar包为主

1.2 路径近者优先原则

优先使用我们自己导入的jar包，依赖中传递的jar包排其次

注意：直接依赖高于间接依赖

2 排除依赖，排除依赖的jar包

操作：通过 <exclusions> <exclusions> 你要排除的依赖 </exclusions> </exclusions> 将要舍弃的jar包的<groupId> 和 <artifactId> 包起来

实例
java 复制代码
 <dependency>
        <groupId>org.springframework</groupId>
        <artifactId>spring-webmvc</artifactId>
        <version>4.2.4.RELEASE</version>
        
        <exclusions>
            <exclusion>
                <groupId>org.springframework</groupId>
                <artifactId>spring-core</artifactId>
            </exclusion>
        </exclusions>
    </dependency>
3 锁定版本

操作：使用 <dependencyManagement> <dependencies>你锁定的依赖【失效】 </dependencies> </dependencyManagement> 标签将你想要让哪一个依赖失效包起来。

实例
java 复制代码
 
    <dependencyManagement>
        <dependencies>
            <dependency>
                <groupId>org.springframework</groupId>
                <artifactId>spring-core</artifactId>
                <version>5.0.2.RELEASE</version>
            </dependency>
        </dependencies>
    </dependencyManagement>
    
    <dependencies>
    	<dependency>
            <groupId>org.springframework</groupId>
            <artifactId>spring-core</artifactId>
        </dependency>
    </dependencies>

问题

我现在就有一个问题：我们知道我们的tomcat内置了servlet jar包在bin目录下，为什么我们还要引入该jar包的依赖，这样不会导致刚刚讲的依赖冲突吗？【maven 构建的项目不知道选择哪一个】

答案：在我这2024.1.1版本的IDEA中通过maven 构建的项目,即使你添加了依赖坐标在pom文件中，并且你还没有表示依赖的范围，【一般是把范围设置为package】但这样也有很大概率不会报错的。

但是我依旧希望，如果你是在pom文件中，引入servlet jar包的依赖坐标，可以给这个依赖添加依赖范围【一般是把范围设置为package】

原因是：

1 maven构建项目中，即使你没有给这个依赖添加依赖范围，他会默认为依赖范围是在编译阶段有效，因此当你把项目部署tomcat 服务器,后你添加的依赖不再起作用，因此不会产生依赖冲突。

2根据使用maven提供的依赖调解原则 (自动) ：第一声明的优先，首先肯定是tomcat 自己的提供的servlet依赖，其次才是我们在pom文件中添加的，