SSM
Spring + SpringMVC + MyBatis
1 Maven
自动化构建 / 测试 / 打包 / 打包项目, 大大提高了开发效率和质量
功能: 构建管理和依赖管理
1.1 GAVP四个属性
Maven 中的 GAVP 是指 GroupId、ArtifactId、Version、Packaging 等四个属性的缩写，其中前三个是必要的，而 Packaging 属性为可选项。这四个属性主要为每个项目在maven仓库总做一个标识，类似人的《姓-名》。有了具体标识，方便maven软件对项目进行管理和互相引用！
GAV遵循一下规则：
1） GroupID 格式：com.{公司/BU }.业务线.[子业务线]，最多 4 级。
说明：{公司/BU} 例如：alibaba/taobao/tmall/aliexpress 等 BU 一级；子业务线可选。
正例：com.taobao.tddl 或 com.alibaba.sourcing.multilang com.atguigu.java
2） ArtifactID 格式：产品线名-模块名。语义不重复不遗漏，先到仓库中心去查证一下。
正例：tc-client / uic-api / tair-tool / bookstore
3） Version版本号格式推荐：主版本号.次版本号.修订号 1.0.0
1） 主版本号：当做了不兼容的 API 修改，或者增加了能改变产品方向的新功能。
2） 次版本号：当做了向下兼容的功能性新增（新增类、接口等）。
3） 修订号：修复 bug，没有修改方法签名的功能加强，保持 API 兼容性。
例如： 初始→1.0.0 修改bug → 1.0.1 功能调整 → 1.1.1等
Packaging定义规则：
指示将项目打包为什么类型的文件，idea根据packaging值，识别maven项目类型！
packaging 属性为 jar（默认值），代表普通的Java工程，打包以后是.jar结尾的文件。
packaging 属性为 war，代表Java的web工程，打包以后.war结尾的文件。
packaging 属性为 pom，代表不会打包，用来做继承的父工程
1.2 项目结构
Maven 是一个强大的构建工具，它提供一种标准化的项目结构，可以帮助开发者更容易地管理项目的依赖、构建、测试和发布等任务。以下是 Maven Web 程序的文件结构及每个文件的作用：
|-- pom.xml # Maven 项目管理文件
|-- src
|-- main # 项目主要代码
| |-- java # Java 源代码目录
| | `-- com/example/myapp # 开发者代码主目录
| | |-- controller # 存放 Controller 层代码的目录
| | |-- service # 存放 Service 层代码的目录
| | |-- dao # 存放 DAO 层代码的目录
| | `-- model # 存放数据模型的目录
| |-- resources # 资源目录，存放配置文件、静态资源等
| | |-- log4j.properties # 日志配置文件
| | |-- spring-mybatis.xml # Spring Mybatis 配置文件
| | `-- static # 存放静态资源的目录
| | |-- css # 存放 CSS 文件的目录
| | |-- js # 存放 JavaScript 文件的目录
| | `-- images # 存放图片资源的目录
| `-- webapp # 存放 WEB 相关配置和资源
| |-- WEB-INF # 存放 WEB 应用配置文件
| | |-- web.xml # Web 应用的部署描述文件
| | `-- classes # 存放编译后的 class 文件
| `-- index.html # Web 应用入口页面
`-- test # 项目测试代码
|-- java # 单元测试目录
`-- resources # 测试资源目录
1.3 Maven核心功能依赖和构建管理
pom.xml
<!-- 模型版本 -->
<modelVersion>4.0.0</modelVersion>
<!-- 公司或者组织的唯一标志，并且配置时生成的路径也是由此生成， 如com.companyname.project-group，maven会将该项目打成的jar包放本地路径：/com/companyname/project-group -->
<groupId>com.companyname.project-group</groupId>
<!-- 项目的唯一ID，一个groupId下面可能多个项目，就是靠artifactId来区分的 -->
<artifactId>project</artifactId>
<!-- 版本号 -->
<version>1.0.0</version>
<!--打包方式
默认：jar
jar指的是普通的java项目打包方式！ 项目打成jar包！
war指的是web项目打包方式！项目打成war包！
pom不会讲项目打包！这个项目作为父工程，被其他工程聚合或者继承！后面会讲解两个概念
-->
<packaging>jar/pom/war</packaging>
<!--声明版本,提取版本号,统一管理-->
<properties>
<!--命名随便,内部制定版本号即可！-->
<!--声明一个变量 声明完变量以后,在其他的位置可以引用${junit.version}-->
<junit.version>4.11</junit.version>
<!-- 也可以通过 maven规定的固定的key，配置maven的参数！如下配置编码格式！-->
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
<project.reporting.outputEncoding>UTF-8</project.reporting.outputEncoding>
</properties>
<dependencies>
</dependencies>
<!--
第三方依赖信息声明
通过编写依赖jar包的gav必要属性，引入第三方依赖！
scope属性是可选的，可以指定依赖生效范围！
依赖信息查询方式：
1. maven仓库信息官网 https://mvnrepository.com/
2. mavensearch插件搜索 √
-->
<dependencies>
<!-- 引入具体的依赖包 是通过GAV信息来定位的-->
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<!--引用properties声明版本 -->
<version>${junit.version}</version>
</dependency>
<dependency>
<groupId>log4j</groupId>
<artifactId>log4j</artifactId>
<version>1.2.17</version>
<!--
生效范围
- compile ：main目录 test目录 打包打包 [默认]
- provided：main目录 test目录 Servlet
- runtime： 打包运行 MySQL
- test: test目录 junit
-->
<scope>runtime</scope>
</dependency>
</dependencies>
依赖传递: 导入依赖, 会自动导入以来的依赖 简化了依赖的导入, 确保依赖的版本无冲突
依赖冲突: 发现已经存在依赖(重复依赖) 会终止依赖传递 避免循环依赖和重复依赖
解决依赖冲突（如何选择重复依赖）方式：
1. 自动选择原则
- 短路优先原则（第一原则）
A—>B—>C—>D—>E—>X(version 0.0.1)
A—>F—>X(version 0.0.2)
则A依赖于X(version 0.0.2)。
- 依赖路径长度相同情况下，则“先声明优先”（第二原则）
A—>E—>X(version 0.0.1)
A—>F—>X(version 0.0.2)
在<depencies></depencies>中，先声明的，路径相同，会优先选择！
1.4 Maven构建管理和插件配置
项目构建是指将源代码、依赖库和资源文件等转换成可执行或可部署的应用程序的过程，在这个过程中包括编译源代码、链接依赖库、打包和部署等多个步骤。
主动触发场景：
- 重新编译 : 编译不充分, 部分文件没有被编译!
- 打包 : 独立部署到外部服务器软件,打包部署
- 部署本地或者私服仓库 : maven工程加入到本地或者私服仓库,供其他工程使用
命令方式构建:
语法: mvn 构建命令 构建命令…
| 命令 | 描述 |
|---|---|
| mvn clean | 清理编译或打包后的项目结构,删除target文件夹 |
| mvn compile | 编译项目，生成target文件 |
| mvn test | 执行测试源码 (测试) |
| mvn site | 生成一个项目依赖信息的展示页面 |
| mvn package | 打包项目，生成war / jar 文件 |
| mvn install | 打包后上传到maven本地仓库(本地部署) |
| mvn deploy | 只打包，上传到maven私服仓库(私服部署) |
可视化方式构建:
构建命令周期:
构建生命周期可以理解成是一组固定构建命令的有序集合，触发周期后的命令，会自动触发周期前的命令！也是一种简化构建的思路!
-
清理周期：主要是对项目编译生成文件进行清理
包含命令：clean
-
默认周期：定义了真正构件时所需要执行的所有步骤，它是生命周期中最核心的部分
包含命令：compile - test - package - install / deploy
-
报告周期
包含命令：site
打包: mvn clean package
重新编译: mvn clean compile
本地部署: mvn clean install
1.5 Maven继承特性
Maven 继承是指在 Maven 的项目中，让一个项目从另一个项目中继承配置信息的机制。继承可以让我们在多个项目中共享同一配置信息，简化项目的管理和维护工作。
在父工程中统一管理项目中的依赖信息,进行统一版本管理!
父工程不打包,也不写代码
啊啊啊啊啊 这里花了时间 好在还是搞定了
pom.xml中有<dependency>和<dependencyManagement>两种
其中<dependencyManagement>是不导入依赖的,只是声明依赖，并不自动实现引入，因此子项目需要显示的声明需要用的依赖。只有在子项目中写了该依赖项，并且没有指定具体版本，才会从父项目中继承该项
1.6 Maven聚合特性
Maven 聚合是指将多个项目组织到一个父级项目中，通过触发父工程的构建,统一按顺序触发子工程构建的过程!!
聚合和继承的区别
继承是子工程配置<parent>信息指定父工程, 聚合是父工程配置<modules>信息指定子工程
Maven核心掌握总结
| 核心点 | 掌握目标 |
|---|---|
| 安装 | maven安装、环境变量、maven配置文件修改 |
| 工程创建 | gavp属性理解、JavaSE/EE工程创建、项目结构 |
| 依赖管理 | 依赖添加、依赖传递、版本提取、导入依赖错误解决 |
| 构建管理 | 构建过程、构建场景、构建周期等 |
| 继承和聚合 | 理解继承和聚合作用、继承语法和实践、聚合语法和实践 |
依赖导入失败场景和解决方案
在使用 Maven 构建项目时，可能会发生依赖项下载错误的情况，主要原因有以下几种：
1. 下载依赖时出现网络故障或仓库服务器宕机等原因，导致无法连接至 Maven 仓库，从而无法下载依赖。
2. 依赖项的版本号或配置文件中的版本号错误，或者依赖项没有正确定义，导致 Maven 下载的依赖项与实际需要的不一致，从而引发错误。
3. 本地 Maven 仓库或缓存被污染或损坏，导致 Maven 无法正确地使用现有的依赖项，并且也无法重新下载！
解决方案：
1. 检查网络连接和 Maven 仓库服务器状态。
2. 确保依赖项的版本号与项目对应的版本号匹配，并检查 POM 文件中的依赖项是否正确。
3. 清除本地 Maven 仓库缓存（lastUpdated 文件），因为只要存在lastupdated缓存文件，刷新也不会重新下载。本地仓库中，根据依赖的gav属性依次向下查找文件夹，最终删除内部的文件，刷新重新下载即可！
扫一扫
1100
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
