Maven

Posted 2020-12-19 ---------zjh---------

Maven

1. 什么是Maven

   Maven 在美国是一个口语化的词语，代表专家、内行的意思。一个对 Maven 比较正式的定义是这么说的：Maven 是一个项目管理工具，它包含了一个项目对象模型 (POM：Project Object Model)，一组标准集合，一个项目生命周期(Project Lifecycle)，一个依赖管理系统(Dependency Management System)，和用来运行定义在生命周期阶段(phase)中插件(plugin)目标(goal)的逻辑。

   试想，如果现在有一种工具，可以把你从上面的繁琐工作中解放出来，能帮你构建工程，管理 jar包，编译代码，还能帮你自动运行单元测试，打包，生成报表，甚至能帮你部署项目，生成 Web 站点，你会心动吗？Maven 就可以解决上面所提到的这些问题。

2. Maven工程的执行过程

   maven 工程中不直接将 jar 包导入到工程中，而是通过在pom.xml 文件中添加所需 jar包的坐标，这样就很好的避免了 jar 直接引入进来，在需要用到 jar 包的时候，只要查找pom.xml 文件，再通过 pom.xml 文件中的坐标，到一个专门用于”存放 jar 包的仓库”(maven 仓库)中根据坐标从而找到这些 jar 包，再把这些 jar 包拿去运行。

Maven安装

1. Apache-maven-3.5.2 下载地址：http://archive.apache.org/dist/maven/maven-3/

2. 电脑上需安装 java 环境，安装 JDK1.7 + 版本（将JAVA_HOME/bin 配置环境变量 path ）

3. 配置 MAVEN_HOME ，变量值就是你的 maven 安装 的路径（bin 目录之前一级目录）

4. 通过 mvn -v命令检查 maven 是否安装成功

Maven仓库

1. Maven仓库的分类

   • 本地仓库 ：用来存储从远程仓库或中央仓库下载的插件和 jar 包，项目使用一些插件或 jar 包，优先从本地仓库查找

     • 默认本地仓库位置在 ${user.dir}/.m2/repository，${user.dir}表示 windows 用户目录

   • 远程仓库：如果本地需要插件或者 jar 包，本地仓库没有，默认去远程仓库下载。远程仓库可以在互联网内也可以在局域网内。

   • 中央仓库 ：在 maven 软件中内置一个远程仓库地址 http://repo1.maven.org/maven2 ，它是中央仓库，服务于整个互联网，它是由 Maven 团队自己维护，里面存储了非常全的 jar 包，它包含了世界上大部分流行的开源项目构件。

2. 建立属于自己的本地仓库

   1. 在任意一个地方新建文件夹repository。

   2. 在 MAVE_HOME/conf/settings.xml 文件中配置本地仓库位置（maven 的安装目录下）

   3. 在localRepository标签内填写刚才创建的文件夹的路径

3. 全局 setting 与用户 setting

   1. 全局配置：在 maven 安装目录下的有 conf/setting.xml 文件，此 setting.xml 文件用于 maven 的所有 project项目

   2. 用户配置：默认在${user.dir} /.m2/settings.xml 目录中

   3. maven 会先找用户配置，如果找到则以用户配置文件为准，否则使用全局配置文件。

4. Maven 工程的目录结构

   • 作为一个 maven 工程，它的 src 目录和 pom.xml 是必备的。

   • 进入 src 目录后，我们发现它里面的目录结构如下：

     • src/main/java —— 存放项目的.java 文件

     • src/main/resources —— 存放项目资源文件，如 spring, hibernate 配置文件

     • src/test/java —— 存放所有单元测试.java 文件，如 JUnit 测试类

     • src/test/resources —— 测试资源文件

     • target —— 项目输出位置，编译后的 class 文件会输出到此目录

     • pom.xml——maven 项目核心配置文件

     • 注意：如果是普通的 java 项目，那么就没有 webapp 目录

Maven常用命令

• compile 是 maven 工程的编译命令，作用是将 src/main/java 下的文件编译为 class 文件输出到 target目录下

• test 是 maven 工程的测试命令 mvn test，会执行 src/test/java 下的单元测试类。

• clean 是 maven 工程的清理命令，执行 clean 会删除 target 目录及内容。

• package 是 maven 工程的打包命令，对于 java 工程执行 package 打成 jar 包，对于 web 工程打成 war包。

• install 是 maven 工程的安装命令，执行 install 将 maven 打成 jar 包或 war 包发布到本地仓库。从运行结果中，可以看出：当后面的命令执行时，前面的操作过程也都会自动执行

Maven指令的生命周期

• maven 对项目构建过程分为三套相互独立的生命周期，请注意这里说的是“三套”，而且“相互独立”，

• 这三套生命周期分别是：

  • Clean Lifecycle ：清理生命周期 ->在进行真正的构建之前进行一些清理工作。

  • Default Lifecycle：默认生命周期 -> 构建的核心部分，编译，测试，打包，部署等等。

  • Site Lifecycle ：站点生命周期 ->生成项目报告，站点，发布站点。

Maven的概念模型

• 项目对象模型 (Project Object Model)

  • 一个 maven 工程都有一个 pom.xml 文件，通过 pom.xml 文件定义项目的坐标、项目依赖、项目信息、插件目标等。

• 依赖管理系统(Dependency Management System)

  • 通过 maven 的依赖管理对项目所依赖的 jar 包进行统一管理。

• 一个项目生命周期(Project Lifecycle)

  • 使用 maven 完成项目的构建，项目构建包括：清理、编译、测试、报告、打包、部署等过程

• 插件(plugin)目标(goal)

  • maven 管理项目生命周期过程都是基于插件完成的

idea 开发 maven 项目

1. 打开File的Settings 配置 maven

2. 在配置maven中的runner里 的VM option中添加-DarchestypeCatalog=internal 在不联网的情况下可以使用骨架创建maven工程

总结

• 坐标定义

在 pom.xml 中定义坐标，内容包括：groupId、artifactId、version，详细内容如下：
<!--项目名称，定义为组织名+项目名，类似包名-->
<groupId>cn.itcast.maven</groupId>
<!-- 模块名称 -->
<artifactId>maven-first</artifactId>
<!-- 当前项目版本号，snapshot 为快照版本即非正式版本，release 为正式发布版本 -->
<version>0.0.1-SNAPSHOT</version>
<packaging > ：打包类型
jar：执行 package 会打成 jar 包
war：执行 package 会打成 war 包
pom ：用于 maven 工程的继承，通常父工程设置为 pom

• pom 基本配置

pom.xml 是 Maven 项目的核心配置文件，位于每个工程的根目录，基本配置如下：
<project > ：文件的根节点 .
<modelversion > ： pom.xml 使用的对象模型版本
<groupId > ：项目名称，一般写项目的域名
<artifactId > ：模块名称，子项目名或模块名称
<version > ：产品的版本号 . 
<packaging > ：打包类型，一般有 jar、war、pom 等
<name > ：项目的显示名，常用于 Maven 生成的文档。 
<description > ：项目描述，常用于 Maven 生成的文档
<dependencies> ：项目依赖构件配置，配置项目依赖构件的坐标
<build> ：项目构建配置，配置编译、运行插件等。

• 依赖范围

  A 依赖 B，需要在 A 的 pom.xml 文件中添加 B 的坐标，添加坐标时需要指定依赖范围，依赖范围包括：

compile：编译范围，指 A 在编译时依赖 B，此范围为默认依赖范围。编译范围的依赖会用在编译、测试、运行，由于运行时需要所以编译范围的依赖会被打包。 
provided：provided 依赖只有在当 JDK 或者一个容器已提供该依赖之后才使用， provided 依赖在编译和测试时需要，在运行时不需要，比如：servlet api 被 tomcat 容器提供。
runtime：runtime 依赖在运行和测试系统的时候需要，但在编译的时候不需要。比如：jdbc的驱动包。由于运行时需要所以runtime 范围的依赖会被打包。 
test：test 范围依赖 在编译和运行时都不需要，它们只有在测试编译和测试运行阶段可用，比如：junit。由于运行时不需要所以 test范围依赖不会被打包。
system：system 范围依赖与 provided 类似，但是你必须显式的提供一个对于本地系统中 JAR文件的路径，需要指定systemPath 磁盘路径，system依赖不推荐使用。

 

 

在 maven-web 工程中测试各各 scop。
测试总结：
? 默认引入 的 jar 包 ------- compile 【默认范围 可以不写】（编译、测试、运行 都有效 ） 
? servlet-api 、jsp-api ------- provided （编译、测试 有效， 运行时无效 防止和 tomcat 下 jar 冲突）
? jdbc 驱动 jar 包 ---- runtime （测试、运行 有效 ）
? junit ----- test （测试有效）
依赖范围由强到弱的顺序是：compile>provided>runtime>test