Maven
maven官网：https://maven.apache.org/what-is-maven.html
Maven 是一款为Java 项目管理构建、依赖管理的工具(软件)，使用 Maven 可以自动化构建、测试、打包和发布项目，大大提高了开发效率和质量。
Maven就是一个软件，掌握安装、配置、以及基本功能**(项目构建:依赖管理)** 的理解和便用即可
maven是一个依赖管理工具。
Maven 可以管理项目的依赖，包括自动下载所需依赖库、自动下载依赖需要的依赖并且保证版本没有冲突、依赖版本管理等。通过 Maven，我们可以方便地维护项目所依赖的外部库，避免版本冲突和转换错误等，而我们仅仅需要编写配置即可。
maven是一个构建工具
项目构建是指将源代码、配置文件、资源文件等转化为能够运行或部署的应用程序或库的过程。Maven 可以管理项目的编译、测试、打包、部署等构建过程。通过实现标准的构建生命周期，Maven 可以确保每一个构建过程都遵循同样的规则和最佳实践。同时，Maven 的插件机制也使得开发者可以对构建过程进行扩展和定制。主动触发构建，只需要简单的命令操作即可。
maven工作原理模型图
maven的安装
根据自己的idea安装对应的maven，最好是安装稳定的maven
下载路径：https://maven.apache.org/docs/history.html
maven配置
1.配置本地仓库
<localRepository>D:\IDEA_java\Maven\maven-respository</localRepository>
2.配置国内阿里镜像
<mirror>
<id>alimaven</id>
<name>aliyun maven</name>
<url>http://maven.aliyun.com/nexus/content/groups/public/</url>
<mirrorOf>central</mirrorOf>
</mirror>
3.配置jdk17版本项目构建
<profile>
<id>jdk-17</id>
<activation>
<activeByDefault>true</activeByDefault>
<jdk>17</jdk>
</activation>
<properties>
<maven.compiler.source>17</maven.compiler.source>
<maven.compiler.target>17</maven.compiler.target>
<maven.compiler.compilerVersion>17</maven.compiler.compilerVersion>
</properties>
</profile>
创建maven项目
基于IDEA进行Maven工程构建
1.构建概念和构建过程
项目构建是指将源代码、依赖库和资源文件等转换成可执行或可部署的应用程序的过程，在这个过程中包括编译源代码、链接依赖库、打包和部署等多个步骤。
项目构建是软件开发过程中至关重要的一部分，它能够大大提高软件开发效率，使得开发人员能够更加专注于应用程序的开发和维护，而不必关心应用程序的构建细节。
同时，项目构建还能够将多个开发人员的代码汇合到一起，并能够自动化项目的构建和部署，大大降低了项目的出错风险和提高开发效率。常见的构建工具包括 Maven、Gradle、Ant等。
2.命令方式项目构建
| 命令 | 描述 |
|---|---|
| mvn compile | 编译项目，生成target文件 |
| mvn package | 打包项目，生成jar或war文件 |
| mvn clean | 清理编译或打包后的项目结构 |
| mvn install | 打包后上传到maven本地仓库 |
| mvn deploy | 只打包，上传到maven私服仓库 |
| myn site | 生成站点 |
| mvn test | 执行测试源码 |
测试类与测试方法的要求
测试类与测试方法都有命名要求：都需要含有“test或者Test”！！！否则识别不到，或者会报错。
例：
public class MavenTest{
@Test
public void testAssert(){
}
}
一般是先清理再测试即：先执行mvn clean()，再执行mvn compile。
war包打包插件
war包打包插件和jdk版本不匹配，pom.xml添加以下代码即可
<build>
<!-- jdk17 和 war包版本插件不匹配-->
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-war-plugin</artifactId>
<version>3.2.2</version>
</plugin>
</plugins>
</build>
打包(package)和安装(install)的区别
打包是将工程打成jar或war文件，保存在target目录下。
安装是将当前工程所生成的jar或war文件，安装到本地仓库，会按照坐标保存到指定位置。
插件、命令、周期三者关系(了解)
周期——>包含若干命令一>包含若干插件
使用周期命令构建，简化构建过程!
最终进行构建的是插件!
基于IDEA进行Maven依赖管理
Maven 依赖管理是 Maven 软件中最重要的功能之一。Maven 的依赖管理能够帮助开发人员自动解决软件包依赖问题，使得开发人员能够轻松地将其他开发人员开发的模块或第三方框架集成到自己的应用程序或模块中，避免出现版本冲突和依赖缺失等问题。
我们通过定义 POM 文件，Maven 能够自动解析项目的依赖关系，并通过 Maven 仓库自动下载和管理依赖，从而避免了手动下载和管理依赖的繁琐工作和可能引发的版本冲突问题。
总之，Maven 的依赖管理是 Maven 软件的一个核心功能之一，使得软件包依赖的管理和使用更加智能和方便,简化了开发过程中的工作，并提高了软件质量和可维护性。
依赖查询官网
官网地址：https://mvnrepository.com/
依赖范围
| 依赖范围 | 描述 |
|---|---|
| compile | 编译依赖范围，scope 元素的缺省值。使用此依赖范围的 Maven 依赖，对于三种 classpath 均有效，即该 Maven 依赖在上述三种 classpath 均会被引入。例如，log4j在编译、测试、运行过程都是必须的。 |
| test | 测试依赖范围。使用此依赖范围的 Maven 依赖，只对测试 classpath 有效。例如，junit 依赖只有在测试阶段才需要。 |
| provideed | 已提供依赖范围。使用此依赖范围的 Maven 依赖，只对编译 classpath 和测试 classpath 有效。例如!servlet-api依赖对于编译、测试阶段而言是需要的，但是运行阶段，由于外部容器已经提供，故不需要 Maven 重复引入该依赖。 |
| runtime | 运行时依赖范围。使用此依赖范围的 Maven 依赖，只对测试 classpath、运行 classpath 有效例如，JDBC驱动实现依赖，其在编译时只需JDK提供的JDBC接口即可，只有测试、运行阶段才需要实现了JDBC接口的驱动。 |
| system | 系统依赖范围，其效果与 provided 的依赖范围一致。其用于添加非 Maven 仓库的本地依赖，通过依赖元素 dependency 中的 systemPath 元素指定本地依赖的路径。鉴于使用其会导致项目的可移植性降低，一般不推荐便用。 |
| import | 导入依赖范围，该依赖范围只能与 dependencyManagement 元素配合便用，其功能是将目标pom.xml 文件中 dependencyManagement 的配置导入合并到当前 pom.xml 的dependencyManagement 中。 |
maven查询依赖网址
网址地址：https://mvnrepository.com/
Maven工程依赖下载失败错误解决(重点)
在使用 Maven 构建项目时，可能会发生依赖项下载错误的情况，主要原因有以下几种:
1.下载依赖时出现网络故障或仓库服务器宕机等原因，导致无法连接至 Maven 仓库，从而无法下载依赖2.依赖项的版本号或配置文件中的版本号错误，或者依赖项没有正确定义，导致 Maven 下载的依赖项与实际需要的不一致，从而引发错误。
3.本地 Maven 仓库或缓存被污染或损坏，导致 Maven 无法正确地使用现有的依赖项。解决方案:
1.检査网络连接和 Maven 仓库服务器状态
2.确保依赖项的版本号与项目对应的版本号匹配，并检査 POM 文件中的依赖项是否正确。
3.清除本地, Maven 仓库缓存(lastUpdated 文件)，因为只要存在lastupdated缓存文件，刷新也不会重新下载。本地仓库中，根据依赖的gav属性依次向下查找文件夹，最终删除内部的文件，刷新重新下载即可!
例如:pom.xml依赖。
Maven工程Build构建配置
项目构建是指将源代码、依赖库和资源文件等转换成可执行或可部署的应用程序的过程，在这个过程中包括编译源代码、链接依赖库、打包和部署等多个步骤。
默认情况下，构建不需要额外配置，都有对应的缺省配置。当然了，我们也可以在pom.xml定制一些配置，来修改默认构建的行为和产物!
例口:
-
指定构建打包文件的名称，非默认名称
<!--默认的打包名称:artifactid+erson.打包方式--> <build> <finalName>定义打包名称</finalName> </build> -
制定构建打包时，指定包含文件格式和排除文件
- 指定打包文件
- 如果在java文件夹中添加java类，会自动打包编译到classes文件夹下!
- 但是在java文件夹中添加xmI文件，默认不会被打包!
- 默认情况下，按照maven工程结构放置的文件会默认被编译和打包!
- 打包插件版本过低，配置更高版本插件
构建配置是在pom.xml/build标签中指定!
常用的插件:修改jdk版本、tomcat插件、mybatis分页插件、mybatis逆向工程插件等等!
<build>
<plugins>
<!--java编译插件，配jdk的编译版本-->
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<configuration>
<source>1.8</source>
<target>1.8</target>
<encoding>UTF-8</encoding>
</configuration>
</plugin>
<!--tomcat插件 -->
<plugin>
<groupId>org.apache.tomcat.maven</groupId>
<artifactId>tomcat7-maven-plugin</artifactId>
<version>2.2</version>
<configuration>
<port>8090</port>
<path>/</path>
<uriEncoding>UTF-8</uriEncoding>
<server>tomcat7</server>
</configuration>
</plugin>
</plugins>
</build>
Maven依赖传递和依赖冲突
Maven依赖传递特性
概念
假如有Maven项目A，项目B依赖A，项目C依赖B。那么我们可以说C依赖A。也就是说，依赖的关系为:C->B->A，那么我们执行项目C时，会自动把B、A都下载导入到C项目的jar包文件夹中，这就是依赖的传递性。
作用：
- 简化依赖导入过程
- 确保依赖版本正确
传递的原则
在A 依赖 B，B 依赖C的前提下，C是否能够传递到 A，取决于B依赖C时使用的依赖范国以及配置：
- B 依赖 C时使用 compile 范围:可以传递
- B 依赖C时使用 test 或 provided 范国:不能传递，所以需要这样的 jar包时，就必须在需要的地方明确配置依赖才可以。
- B 依赖C时，若配置了以下标签，则不能传递
<dependency>
<groupId>com.alibaba</groupId>
<artifactId>druid</artifactId>
<version>1.2.15</version>
<optional>true</optional>
<!-- optional标签可以终止依赖的传递 -->
</dependency>
依赖传递终止
- 非compie范围进行依赖传递
- 使用optional配置终止传递
- 依赖冲突(传递的依赖已经存在)
Maven依赖冲突特性
当直接引用或者间接引用出现了相同的jar包!这时呢，一个项目就会出现相同的重复jar包，这就算作冲突!依赖冲突避免出现重复依赖，并且终止依赖传递!
maven自动解决依赖冲突问题能力，会按照自己的原则，进行重复依赖选择。同时也提供了手动解决的冲突的方式，不过不推荐!
解决依赖冲突(如何选择重复依赖)方式:
- 自动选择原则
- 短路优先原则(第一原则)A->B->C->D->E->X(version 0.0.1)
A->F->X(version 0.0.2 )
则A依赖于X(version 0.0.2)。 - 依赖路径长度相同情况下，则“先声明优先”(第二原则)
A-F->X(version 0.0.1)
A->F->X(version 0.0.2)
在中，先声明的，路径相同，会优先选择!
- 手动排除
即在dependences标签下加入如下代码：
<!--依赖排除-->
<exclusions>
<exclusion>
<groupId>com.alibaba</groupId>
<artifactId>druid</artifactId>
</exclusion>
</exclusions>
maven工程的继承与聚合关系
Maven工程继承关系
-
继承概念
Maven 继承是指在 Maven 的项目中，让一个项目从另一个项目中继承配置信息的机制。继承可以让我们在多个项目中共享同一配置信息，简化项目的管理和维护工作。 -
继承作用
在父工程中统一管理项目中的依赖信息。
它的背景是:- 对一个比较大型的项目进行了模块拆分
- 一个 project 下面，创建了很多个 module。
- 每一个 module 都需要配置自己的依赖信息。
它背后的需求是:
- 在每一个 module 中各自维护各自的依赖信息很容易发生出入，不易统一管理。
- 使用同一个框架内的不同 jar 包，它们应该是同一个版本，所以整个项目中使用的框架版本需要统一。。
- 使用框架时所需要的 jar 包组合(或者说依赖信息组合)需要经过长期摸索和反复调试，最终确定一个可。用组合。这个耗费很大精力总结出来的方案不应该在新的项目中重新摸索。
通过在父工程中为整个项目维护依毂信息的组合既保证了整个项目使用规范、准确的jar包;又能够将以往的经验沉淀下来，节约时间和精力。
-
继承语法
- 父工程
<!--当前工程作为父工程，它要去管理子工程，所以打包方式必须是pom--> <packaging>pom</packaging>- 子工程
<!--使用parent标签指定当前工程的父工程--> <parent> <groupId>com.wang.maven</groupId> <artifactId>maven_parent</artifactId> <version>1.0-SNAPSHOT</version> </parent> -
父工程依赖统一管理
使用dependencyMangement标签配置对依赖的管理，被管理的依赖并没有真正被引入到子工程中，当子依赖想要继承的时候需要再子依赖的dengpendencies中引入依赖项的groupId和artifactId。而如果使用denpendencies标签，则里面的依赖是完全继承到子工程里面的。
- 父工程声明版本
<!--依赖管理--> <dependencyManagement> <dependencies> <!-- https://mvnrepository.com/artifact/com.alibaba/druid --> <dependency> <groupId>com.alibaba</groupId> <artifactId>druid</artifactId> <version>1.2.7</version> </dependency> <!-- https://mvnrepository.com/artifact/org.junit.jupiter/junit-jupiter-api --> <dependency> <groupId>org.junit.jupiter</groupId> <artifactId>junit-jupiter-api</artifactId> <version>5.9.2</version> <scope>test</scope> </dependency> <!-- https://mvnrepository.com/artifact/javax.servlet/javax.servlet-api --> <dependency> <groupId>javax.servlet</groupId> <artifactId>javax.servlet-api</artifactId> <version>4.0.1</version> <scope>provided</scope> </dependency> </dependencies> </dependencyManagement>- 子工程声明
<dependencies> <!-- https://mvnrepository.com/artifact/com.alibaba/druid --> <dependency> <groupId>com.alibaba</groupId> <artifactId>druid</artifactId> </dependency> </dependencies>
maven工程聚合关系
- 聚合概念
Maven 聚合是指将多个项目组织到一个父级项目中，以便一起构建和管理的机制。聚合可以帮助我们更好地管理一组相关的子项目，同时简化它们的构建和部署过程。 - 聚合作用
- 管理多个子项目：通过聚合，可以将多个子项目组织在一起，方便管理和维护。
- 构建和发布一组相关的项目:通过聚合，可以在一个命令中构建和发布多个相关的项目，简化了部署和维护工作。
- 优化构建顺序1：通过聚合，可以对多个项目进行顺序控制，避免出现构建依赖混乱导致构建失败的情况。
- 统一管理依赖项：通过聚合，可以在父项目中管理公共依赖项和插件，避免重复定义。
- 聚合语法
父项目中包含的子项目列表。
<project>
<groupId>com.example</groupId>
<artifactId>parent-project</artifactId>
<packaging>pom</packaging>
<version>1.0.0</version>
<modules>
<!--这里是子工程路径，不是子工程名-->
<module>child-project1</module>
<module>child-project2</module>
</modules>
</project>
- 聚合演示
通过触发父工程构建命令、引发所有子模块构建!产生反应堆!
maven私服
- 私服简介
Maven 私服是一种特殊的Maven远程仓库，它是架设在局域网内的仓库服务，用来代理位于外部的远程仓库(中央仓库、其他远程公共仓库)。
当然也并不是说私服只能建立在局域网，也有很多公司会直接把私服部署到公网，具体还是得看公司业务的性质是否是保密的等等，因为局域网的话只能在公司用，部署到公网的话员工在家里也可以办公使用。
建立了 Maven 私服后，当局域网内的用户需要某个构件时，会按照如下顺序进行请求和下载。
- 请求本地仓库，若本地仓库不存在所需构件，则跳转到第2步;
- 请求 Maven 私服，将所需构件下载到本地仓库，若私服中不存在所需构件，则跳转到第 3步。
- 请求外部的远程仓库，将所需构件下载并缓存到 Maven 私服，若外部远程仓库不存在所需构件，则 Maven 直接报错。
此外，一些无法从外部仓库下载到的构件，也能从本地上传到私服供其他人使用。
- Maven私服的优势
- 节省外网带宽
消除对外部远程仓库的大量重复请求(会消耗很大量的带宽)，降低外网带宽压力。 - 下载速度更快
Maven私服位于局域网内，从私服下载构建更快更稳定 - 便于部署第三方构件
有些构件无法从任何一个远程仓库中获得(如:公司或组织内部的私有构件、0racle的IDBC驱动等)，建立私服之后，就可以将这些构件部署到私服中，供内部Maven项目使用。 - 提高项目的稳定性，增强对项目的控制
如果不建立私服，那么Maven项目的构件就高度依赖外部的远程仓库，若外部网络不稳定，则项目的构建过程也会变得不稳定。建立私服后，即使外部网络状况不佳甚至中断，只要私服中已经缓存了所需的构件，Maven也能够正常运行。私服软件(如:Nexus)提供了很多控制功能(如:权限管理、RELEASE/SNAPSHOT版本控制等)，可以对仓库进行一些更加高级的控制。 - 降低中央仓库得负荷压力
由于私服会缓存中央仓库得构件，避免了很多对中央仓库的重复下载，降低了中央仓库的负荷。
- 节省外网带宽
Nexus仓库
下载地址:https://help.sonatype.com/repomanager3/product-information/download
Nexus仓库说明
| 仓库类型 | 说明 |
|---|---|
| proxy | 某个远程仓库的代理 |
| group | 存放：通过 Nexus 获取的第三方jar 包 |
| hosted | 存放：本团队其他开发人员部署到 Nexus的jar 包 |
| 仓库名称 | 说明 |
|---|---|
| maven-central | Nexus对 Maven 中央仓库的代理 |
| maven-public | Nexus 默认创建，供开发人员下载使用的组仓库 |
| maven-releases | Nexus 默认创建，供开发人员部署自己jar 包的宿主仓库 要求 releases 版本 |
| maven-snapshots | Nexus 默认创建，供开发人员部署自己jar 包的宿主仓库 要求 snapshots 版本 |
通过Nexus下载jar包
修改本地maven的核心配置文件settings.xml，设置新的本地仓库地址
<!--配黑一个新的 Maven 本地仓库 -->
<localRepository>D:/maven-repository-new</localRepository>
把我们原来配置阿里云仓库地址的 mirror 标签改成下面这样:
<mirror>
<id>nexus-mine</id>
<mirrorOf>central</mirrorOf>
<name>Nexus mine</name>
<url>http://localhost:8081/repository/maven-public/</url>
</mirror>
把上图中看到的地址复制出来即可。如果我们在前面允许了匿名访问，到这里就够了。但如果我们禁用了匿名访问，那么接下来我们还要继续配置 settings.xml:
<server>
<id>nexus-mine</id>
<username>admin</username>
<password>atguigu</password>
</server>
这里需要格外注意：server 标签内的id 标签值必须和 mirror 标签中的 id 值一样。
找一个用到框架的 Maven 工程，执行命令:
mvn clean compile
6.将jar 包部署到 Nexus
maven工程中配置:
<distributionManagement>
<snapshotRepository>
<id>nexus-mine</id>
<name>Nexus Snapshot</name>
<ur1>http://localhost:8081/repository/maven-snapshots/</ur1>
</snapshotRepository>
</distributionManagement>
注意:这里 snapshotRepository的id 标签必须和 settings.xm| 中指定的 mirror 标签的id属性保持一致。
执行部署命令:
mvn deploy
7.引用别人部署的 jar 包
maven工程中配置：
<repositories>
<repository>
<id>nexus-mine</id>
<name>nexus-mine</name>
<ur1>http://localhost:8081/repository/maven-snapshots/</ur1>
<snapshots>
<enabled>true</enabled>
</snapshots>
<releases>
<enabled>true</enabled>
</releases>
</repository>
</repositories>
maven综合案例
需求分析和结构分析
需求案例:搭建一个电商平台项目，该平台包括用户服务、订单服务、通用工具模块等。
项目架构:
- 用户服务：负责处理用户相关的逻辑，例如用户信息的管理、用户注册、登录等
- spring-context 6.0.6
- spring-core 6.0.6
- spring-beans 6.0.6
- commonservice
- 订单服务：负责处理订单相关的逻辑，例如订单的创建、订单支付、退货、订单查看等。
- spring-context 6.0.6
- spring-core 6.0.6
- spring-beans 6.0.6
- spring-security 6.0.6
- commonservice
- 通用模块：负责存储其他服务需要通用工具类，其他服务依赖此模块。
- commons-io 2.11.0
- junit 5.9.2
扫一扫
1482
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
