广州站八个字,主机开通成功网站正在建设中,wordpress主题图片拉伸,wordpress discuz用户目录 1.简介2.Maven项目目录结构2.1 约定目录结构的意义2.2 约定大于配置 3. POM.XML介绍3.2 依赖引用3.3 属性管理 4 Maven生命周期4.1 经常遇到的生命周期4.1 全部生命周期 5.依赖范围#xff08;Scope#xff09;6. 依赖传递6.1 依赖冲突6.2 解决依赖冲突6.2.1 最近依赖者… 目录 1.简介2.Maven项目目录结构2.1 约定目录结构的意义2.2 约定大于配置 3. POM.XML介绍3.2 依赖引用3.3 属性管理 4 Maven生命周期4.1 经常遇到的生命周期4.1 全部生命周期 5.依赖范围Scope6. 依赖传递6.1 依赖冲突6.2 解决依赖冲突6.2.1 最近依赖者优先6.2.2 路径近者优先原则 6.3 依赖排除 7. 聚合项目 1.简介
Maven是一个Java项目管理和构建工具他可以定义项目结构、项目依赖并使用同意的方式进行自动化构建是Java项目中不可缺少的工具。
2.Maven项目目录结构
该目录结构是事先约定好的不可随意变更。 另外还有一个target目录文件夹专门用于存放构建操作输出的结果
2.1 约定目录结构的意义
Maven未来让Java项目构建的过程尽可能自动化完成所以必须约定目录结构的作用。 例如Maven执行编译操作必须先去Java源程序目录读取Java源代码然后执行编译最后把编译结果存放在Target目录。
2.2 约定大于配置
Maven对于目录结构这个问题没有采用配置的方法而是基于约定。这回让我们在开发过程中比较方便。如果在每次创建Maven工程之后还需要对各个目录的位置进行详细的配置那肯定非常麻烦。 目前开发领域的技术趋势是约定大于配置、配置大于编码。
3. POM.XML介绍
了解maven本质上就是了解pom.xml文件夹 一般我们在生成一个maven项目后基础的pom.xml如下所示
?xml version1.0 encodingUTF-8?
project xmlnshttp://maven.apache.org/POM/4.0.0xmlns:xsihttp://www.w3.org/2001/XMLSchema-instancexsi:schemaLocationhttp://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd!--版本相关--modelVersion4.0.0/modelVersion!--本项目坐标信息(每个maven项目都会有唯一的坐标)--!--通过这这三项组成的通过坐标信息可以定位到具体的Jar包信息--!--定位过程是仓库-镜像-找不到报错not found--groupIdcom.ztt/groupId !-- groupId 组织名称一般是域名反写--artifactIduntitled/artifactId !-- artifactId 项目名--version1.0-SNAPSHOT/version !-- version 版本名称--propertiesmaven.compiler.source8/maven.compiler.sourcemaven.compiler.target8/maven.compiler.targetproject.build.sourceEncodingUTF-8/project.build.sourceEncoding/properties/project
3.2 依赖引用
本质上就是如何通过坐标信息引用jar包 maven项目在dependencies/dependencies 引入依赖引入jar包。
在pom.xml添加servlet的依赖 dependencies!-- https://mvnrepository.com/artifact/javax.servlet/javax.servlet-api --dependencygroupIdjavax.servlet/groupIdartifactIdjavax.servlet-api/artifactIdversion3.1.0/version/dependency/dependencies这时候这个依赖就已经添加进来了
3.3 属性管理
pom.xml属性管理一般用properties /properties 包裹。 如下所示同时下面我也介绍了几个常用的属性配置。
!--属性变量--properties!--JDK版本--maven.compiler.source8/maven.compiler.sourcemaven.compiler.target8/maven.compiler.target!--编码--project.build.sourceEncodingUTF-8/project.build.sourceEncoding!--这里也经常用于声明依赖的版本--javax.servlet.version3.1.0/javax.servlet.version/properties注意properties中经常用于生命依赖的版本这样做的好处是可以帮助我们进行统一的版本管理。 具体操作如下。
4 Maven生命周期
4.1 经常遇到的生命周期
clean默认是清除target目录中的所有文件避免将历史版本打到新的包中造成一些不在预期中的问题。 process-resources将资源文件src/main/resources下的文件复制到target/classes目录中。 compile将src/main/java下的代码编译成 class 文件也放到target/classes目录中。 process-test-resources将资源文件src/test/resources下的文件复制到target/test-classes目录中。 test-compile将src/test/java下的代码编译成 class 文件也放到target/test-classes目录中。 test运行单元测试并在target/surefire-reports中生成测试报告。 package将资源文件、class文件、pom文件打包成一个jar/war包。 install将生成的jar包推送到本地仓库中。 deploy将生成的jar包推送到远程仓库中。
IDEA中打开Maven控制界面查看生命周期
4.1 全部生命周期 1. Clean Lifecycle - 清理项目 pre-clean: 在清理之前执行的操作。 clean: 删除所有上一次构建生成的文件。 2. Default Lifecycle - 构建项目: validate: 验证项目是正确的所有必要的信息都已经准备就绪。 initialize: 初始化构建状态例如设置属性。 generate-sources: 生成需要包含在编译中的源代码。 process-sources: 处理源代码例如过滤源代码中的值。 generate-resources: 复制和生成资源文件到指定目录。 process-resources: 处理资源文件例如替换资源中的占位符。 compile: 编译项目的源代码。 process-classes: 处理编译生成的类文件。 generate-test-sources: 生成测试源代码。 process-test-sources: 处理测试源代码。 generate-test-resources: 复制和生成测试资源文件。 process-test-resources: 处理测试资源文件。 test-compile: 编译测试源代码。 process-test-classes: 处理测试编译生成的类文件。 test: 使用单元测试框架运行测试。 prepare-package: 准备打包操作。 package: 将编译后的代码打包成可分发的格式如JAR、WAR。 pre-integration-test: 在集成测试之前执行的操作。 integration-test:处理和部署包到可以运行集成测试的环境中。 post-integration-test: 在集成测试之后执行的操作。 verify: 运行任何检查以验证包是有效的。 install: 安装包到本地仓库使其可以作为其他项目的依赖。 deploy: 将最终的包复制到远程仓库供其他开发人员和项目使用。 3.Site Lifecycle - 生成项目站点 pre-site: 在生成项目站点之前执行的操作。 site: 生成项目报告和文档。 post-site: 在生成项目站点之后执行的操作。 site-deploy: 将生成的站点部署到服务器上。 5.依赖范围Scope
依赖作用范围一般在scope/scope中设置 Maven的依赖范围包括编译、测试、运行\打包(刚入门可以把运行和打包理解成一个) 编译只在main\java的中有效 测试只在main\test中有效 运行\打包项目生成war、jar包时在运行过程中使用到该依赖。 作用范围的建议
所有的Scope都设置成compile也不会影响功能的正常运行同时90%以上的依赖都会使用compile每个依赖会有自己默认的scope同时maven也会对依赖的scope自动补全所以建议用官方提供的scope也没毛病。
6. 依赖传递
在Maven中依赖可以传递的假设存在三个项目项目A、项目B、项目C。假设C依赖BB依赖A那么我们可以根据Maven项目依赖的特征推断出项目C也依赖项目A。
6.1 依赖冲突
依赖冲突通常发生在项目中使用了多个库而这些库又依赖于相同库的不同版本时。这种情况可能导致构建失败或运行时错误因为Java运行时环境要求所有类库的版本必须一致。下面是一个具体的例子来说明依赖冲突
假设你正在开发一个Java Web应用程序并且你的项目有以下依赖关系 你的项目直接依赖于LibraryA版本1.0。 LibraryA又依赖于CommonLib版本1.5。 同时你的项目还直接依赖于LibraryB版本2.0。 而LibraryB也依赖于CommonLib但需要版本2.0。 这里的依赖关系可以表示为 在这个例子中CommonLib的两个不同版本1.5和2.0被引入到项目中这将导致依赖冲突。Maven会尝试根据其依赖解析策略来解决这个冲突但如果没有明确指定版本可能会导致以下问题
构建失败Maven可能无法决定使用哪个版本的CommonLib导致构建失败。运行时错误如果Maven选择了一个版本但在运行时环境中使用了另一个版本的CommonLib可能会导致NoClassDefFoundError或ClassNotFoundException等错误。
6.2 解决依赖冲突
6.2.1 最近依赖者优先
Maven的依赖调解原则通常被称为最近依赖者优先或第一声明者原则First Declaration Rule是Maven处理传递性依赖冲突时使用的一种策略。这个原则确保了依赖冲突可以通过一个简单的规则来解决从而避免了复杂的版本冲突问题。
第一声明者原则的工作原理 依赖树的构建Maven首先构建项目的依赖树包括直接依赖和所有间接依赖。
冲突检测在构建依赖树的过程中Maven会检测到多个依赖项可能依赖于同一个库的不同版本。
选择依赖版本当检测到版本冲突时Maven会选择依赖树中距离项目最近的依赖项指定的版本。换句话说它会选择第一个声明该库依赖的依赖项的版本。
忽略后续声明在依赖树中任何后续声明的相同库的不同版本将被忽略即使它们可能是更新的或更低的版本。
6.2.2 路径近者优先原则
路径近者优先原则Shortest Path Rule是Maven处理依赖冲突时使用的另一种策略它与第一声明者原则有相似之处但更侧重于依赖路径的长度。这个原则确保了在多个依赖项指向同一个库的不同版本时Maven选择路径最短的依赖版本。
路径近者优先原则的工作原理 依赖树构建Maven构建项目的依赖树包括直接依赖和间接依赖。
冲突检测在构建依赖树的过程中Maven检测到多个依赖项可能依赖于同一个库的不同版本。
最短路径选择当检测到版本冲突时Maven会选择依赖路径最短的依赖项指定的版本。依赖路径是指从项目到依赖项的直接距离。
忽略长路径声明即使长路径上的依赖项声明了更新或更低的版本Maven也会忽略它因为根据路径近者优先原则它不是最优选择。
6.3 依赖排除
依赖排除是Maven处理依赖冲突的一种常用方法。以下是如何进行依赖排除的一个具体例子
假设你的项目直接依赖于两个库LibraryA 和 LibraryB。但是LibraryA 和 LibraryB 都间接依赖于同一个库 CommonLib并且它们依赖的 CommonLib 版本不同。为了解决这个冲突你可以选择排除一个版本的 CommonLib并显式地声明你需要的版本作为直接依赖。
以下是pom.xml文件中的依赖配置示例
dependencies!-- 直接依赖LibraryA --dependencygroupIdcom.example/groupIdartifactIdLibraryA/artifactIdversion1.0/version!-- 排除LibraryA中对CommonLib 1.5的依赖 --exclusionsexclusiongroupIdcom.common/groupIdartifactIdCommonLib/artifactId/exclusion/exclusions/dependency!-- 直接依赖LibraryB --dependencygroupIdcom.example/groupIdartifactIdLibraryB/artifactIdversion2.0/version!-- 排除LibraryB中对CommonLib 2.0的依赖 --exclusionsexclusiongroupIdcom.common/groupIdartifactIdCommonLib/artifactId/exclusion/exclusions/dependency!-- 显式声明CommonLib的版本确保使用一致的版本 --dependencygroupIdcom.common/groupIdartifactIdCommonLib/artifactIdversion1.5/version !-- 假设我们决定使用1.5版本 --/dependency/dependencies!-- ... 其他配置 ... --
在这个例子中我们首先排除了 LibraryA 和 LibraryB 中对 CommonLib 的依赖。然后我们添加了一个直接依赖项指定了 CommonLib 的版本为1.5。这样无论 LibraryA 和 LibraryB 依赖的是 CommonLib 的哪个版本Maven都会使用我们显式声明的版本1.5。
通过这种方式你可以控制项目中使用的依赖项的版本避免由于依赖传递带来的版本冲突问题。
7. 聚合项目
Maven聚合项目也称为多模块项目或父项目是一种项目组织方式它允许你将一个大项目分解成多个小的、可管理的模块。每个模块可以独立构建和维护同时仍然可以作为一个整体来构建和分发。 对于项目开发聚合项目有以下好处 模块化将一个大项目分解成多个模块有助于更好地组织代码每个模块负责特定的功能或组件。 重用性模块化使得代码可以在不同项目中重用因为它们可以作为独立的组件进行构建和部署。 并行开发在多模块项目中不同的团队可以同时在不同的模块上工作这有助于提高开发效率和加快开发速度。 依赖管理父项目可以使用部分来统一管理所有子模块的依赖版本确保依赖的一致性。 作为聚合项目其父项目应该
删除src,聚合项目的父项目不承担代码只是作为子项目的管理packaging/packaging 一般为jar或者war,但是作为父项目其不是一个具体的包固其中pom.xml中的应进行packagingpom/packaging设置。利用pom.xml中的 modules /modules管理子工程
