🌊 执行Maven命令
💦 方式一
💦 方式二
如果有需要，还可以给命令后面附加参数：
# -D 表示后面要附加命令的参数，字母 D 和后面的参数是紧挨着的，中间没有任何其它字符 # maven.test.skip=true 表示在执行命令的过程中跳过测试 mvn clean install -Dmaven.test.skip=true
💦 方式三
🌊 创建 Web 模块工程
💦 创建模块
💦 修改打包方式
Web 模块将来打包当然应该是 war 包。
<packaging>war</packaging>
💦 Web 设定
首先打开项目结构菜单：
然后到 Facets 下查看 IDEA 是否已经帮我们自动生成了 Web 设定。正常来说只要我们确实设置了打包方式为 war，那么 IDEA 就会自动生成 Web 设定。
另外，对于 IDEA 2018 诸版本没有自动生成 Web 设定，那么请参照下面两图，我们自己创建：
💦 借助IDEA生成web.xml
💦 设置 Web 资源的根目录
结合 Maven 的目录结构，Web 资源的根目录需要设置为 src/main/webapp 目录。
🌊 工程导入
Maven工程除了自己创建的，还有很多情况是别人创建的。而为了参与开发或者是参考学习，我们都需要导入到 IDEA 中。下面我们分几种不同情况来说明：
💦 来自版本控制系统
目前我们通常使用的都是 Git（本地库） + 码云（远程库）的版本控制系统，结合 IDEA 的相关操作方式请点这里 (opens new window)查看克隆远程库部分。
💦 来自工程目录
直接使用 IDEA 打开工程目录即可。下面咱们举个例子：
💧 工程压缩包
假设别人发给我们一个 Maven 工程的 zip 压缩包：maven-rest-demo.zip。从码云或GitHub上也可以以 ZIP 压缩格式对项目代码打包下载。
💧 解压
如果你的所有 IDEA 工程有一个专门的目录来存放，而不是散落各处，那么首先我们就把 ZIP 包解压到这个指定目录中。
💧 打开
只要我们确认在解压目录下可以直接看到 pom.xml，那就能证明这个解压目录就是我们的工程目录。那么接下来让 IDEA 打开这个目录就可以了。
💧 设置 Maven 核心程序位置
打开一个新的 Maven 工程，和新创建一个 Maven 工程是一样的，此时 IDEA 的 settings 配置中关于 Maven 仍然是默认值：
所以我们还是需要像新建 Maven 工程那样，指定一下 Maven 核心程序位置：
🌊 模块导入
💦 情景重现
在实际开发中，通常会忽略模块（也就是module）所在的项目（也就是project）仅仅导入某一个模块本身。这么做很可能是类似这样的情况：比如基于 Maven 学习 SSM 的时候，做练习需要导入老师发给我们的代码参考。
💦 导入 Java 类型模块
💧 找到老师发的工程目录
💧 复制我们想要导入的模块目录
💧 粘贴到我们自己工程目录下
这个工程（project）是我们事先在 IDEA 中创建好的。
💧 在 IDEA 中执行导入
💧 修改 pom.xml
刚刚导入的 module 的父工程坐标还是以前的，需要改成我们自己的 project。
💧 最终效果
💦 导入 Web 类型模块
其它操作和上面演示的都一样，只是多一步：删除多余的、不正确的 web.xml 设置。如下图所示：
🥽 其他核心概念
🌊 生命周期
💦 作用
为了让构建过程自动化完成，Maven 设定了三个生命周期，生命周期中的每一个环节对应构建过程中的一个操作。
💦 三个生命周期
| 生命周期名称 | 作用 | 各个环节 |
| Clean | 清理操作相关 | pre-clean clean post-clean |
| Site | 生成站点相关 | pre-site site post-site deploy-site |
| Default | 主要构建过程 | validate 检查 generate-sources process-sources 源码 generate-resources 配置文件 process-resources 复制并处理资源文件，至目标目录，准备打包。 compile 编译项目 main 目录下的源代码。 process-classes generate-test-sources process-test-sources generate-test-resources process-test-resources 复制并处理资源文件，至目标测试目录。 test-compile 编译测试源代码。 process-test-classes test 使用合适的单元测试框架运行测试。这些测试代码不会被打包或部署。 prepare-package package 接受编译好的代码，打包成可发布的格式，如JAR。 pre-integration-test integration-test post-integration-test verify install将包安装至本地仓库，以让其它项目依赖。 deploy将最终的包复制到远程的仓库，以让其它开发人员共享；或者部署到服务器上运行（需借助插件，例如：cargo）。 |
💦 特点
- 前面三个生命周期彼此是独立的。
- 在任何一个生命周期内部，执行任何一个具体环节的操作，都是从本周期最初的位置开始执行，直到指定的地方。（本节记住这句话就行了，其他的都不需要记）
Maven 之所以这么设计其实就是为了提高构建过程的自动化程度：让使用者只关心最终要干的即可，过程中的各个环节是自动执行的。
🌊 插件和目标
💦 插件
Maven 的核心程序仅仅负责宏观调度，不做具体工作。具体工作都是由 Maven 插件完成的。例如：编译就是由 maven-compiler-plugin-3.1.jar 插件来执行的。
💦 目标
一个插件可以对应多个目标，而每一个目标都和生命周期中的某一个环节对应。 (目标其实是插件的功能)
Default 生命周期中有 compile 和 test-compile 两个和编译相关的环节，这两个环节对应 compile 和 test-compile 两个目标，而这两个目标都是由 maven-compiler-plugin-3.1.jar 插件来执行的。
🌊 仓库
- 本地仓库：在当前电脑上，为电脑上所有 Maven 工程服务
- 远程仓库：需要联网
- 局域网：我们自己搭建的 Maven 私服，例如使用 Nexus 技术。
- Internet
- 中央仓库
- 镜像仓库：内容和中央仓库保持一致，但是能够分担中央仓库的负载，同时让用户能够就近访问提高下载速度，例如：Nexus aliyun
建议：不要中央仓库和阿里云镜像混用，否则 jar 包来源不纯，彼此冲突。
专门搜索 Maven 依赖信息的网站：https://mvnrepository.com/
