Maven 笔记

博主： moluuser
发布时间：2020 年 05 月 01 日
2100次浏览
暂无评论
8008字数
分类：笔记

开发项目所用技术

maven1

存在问题

一个项目就是一个工程
- 如果项目庞大，就不适合用package划分模块，最好一个模块对应一个工程，利于分工。
- 借助Maven就可以把一个项目拆分成多个工程。
项目中所需jar包必须手动导入到WEB-INF/lib目录下
- 同样的jar包重复出现在不同工程中，造成存储空间浪费，工程臃肿。
- 借助Maven，可以将jar包保存在仓库中，需要jar包的工程只需以坐标方式引用即可。
第三方jar包
- 使用Maven 我们可以享受到一个完全统一规范的jar 包管理体系。你只需要在你的项目中以坐标的方式依赖一个jar 包，Maven 就会自动从中央仓库进行下载，并同时下载这个jar 包所依赖的其他jar 包。
jar包之间的依赖
- Maven 就可以替我们自动的将当前jar 包所依赖的其他所有jar 包全部导入进来，无需人工参与，节约了我们大量的时间和精力。

Maven简介

Maven 是Apache 软件基金会组织维护的一款自动化构建工具，专注服务于Java 平台的项目构建和依赖管理。Maven 这个单词的本意是：专家，内行。读音是['meɪv(ə)n]或['mevn]。
构建过程的几个主要环节

①清理：删除以前的编译结果，为重新编译做好准备。②编译：将Java 源程序编译为字节码文件。③测试：针对项目中的关键点进行测试，确保项目在迭代开发过程中关键点的正确性。④报告：在每一次测试后以标准的格式记录和展示测试结果。⑤打包：将一个包含诸多文件的工程封装为一个压缩文件用于安装或部署。Java 工程对应jar 包，Web工程对应war 包。⑥安装：在Maven 环境下特指将打包的结果——jar 包或war 包安装到本地仓库中。⑦部署：将打包的结果部署到远程仓库或将war 包部署到服务器上运行。

自动化构建：Maven可以自动的从构建过程的起点一直执行到终点

安装Maven

解压Maven核心程序的压缩包，放在一个非中文、无空格的路径下。
配置Maven相关的环境变量
1. MAVEN_HOME 或 M2_HOME变量值为Maven路径 D:\uninstallapp\apache-maven-3.6.3
2. Path 追加
  变量值为 D:\uninstallapp\apache-maven-3.6.3\bin
验证 mvn -v

Maven核心概念

Maven 能够实现自动化构建是和它的内部原理分不开的，这里我们从Maven 的九个核心概念入手，看看Maven 是如何实现自动化构建的。

①POM
②约定的目录结构
③坐标
④依赖管理
⑤仓库管理
⑥生命周期
⑦插件和目标
⑧继承
⑨聚合

约定的目录结构

maven2

我们在开发中如果需要让第三方工具或框架知道我们自己创建的资源在哪，那么基本上就是两种方式：

通过配置的形式
基于第三方工具或框架的约定

        Hello
        |---src
        |---|---main
        |---|---|---java
        |---|---|---resources
        |---|---test
        |---|---|---java
        |---|---|---resources
        |---pom.xml

pom.xml文件为Maven工程的核心配置文件
Project Object Model：项目对象模型。将Java 工程的相关信息封装为对象作为便于操作和管理的模型。
Maven 工程的核心配置。可以说学习Maven 就是学习pom.xml 文件中的配置。
DOM Document Object Model 文档对象模型

Maven常用命令

执行与构建过程相关的Maven命令，必须进入pom.xml 所在的目录。
常用命令：
1. mvn clean : 清理
2. mvn compile : 编译主程序
3. mvn test-compile : 编译测试程序
4. mvn test : 执行测试
5. mvn package : 打包
6. mvn install ：安装
7. mvn site ：生成站点

坐标

使用如下三个向量在Maven 的仓库中唯一的确定一个Maven 工程。

groupid：公司或组织的域名倒序+当前项目名称
artifactId：当前项目的模块名称
version：当前模块的版本

<project xmlns = "http://maven.apache.org/POM/4.0.0"
    xmlns:xsi = "http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation = "http://maven.apache.org/POM/4.0.0
    http://maven.apache.org/xsd/maven-4.0.0.xsd">
 
    <!-- 模型版本 -->
    <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</version>
</project>

Maven 工程的坐标与仓库中路径的对应关系

如何通过坐标到仓库中查找jar 包？

将gav 三个向量连起来com.atguigu.maven+Hello+0.0.1-SNAPSHOT
以连起来的字符串作为目录结构到仓库中查找
com/atguigu/maven/Hello/0.0.1-SNAPSHOT/Hello-0.0.1-SNAPSHOT.jar

注意：我们自己的Maven 工程必须执行安装操作才会进入仓库。安装的命令是：mvn install

仓库

maven3

仓库中的文件

Maven 的插件
我们自己开发的项目的模块
第三方框架或工具的jar 包

不管是什么样的jar 包，在仓库中都是按照坐标生成目录结构，所以可以通过统一的方式查询或依赖。

依赖

依赖的目的

当A jar 包用到了B jar 包中的某些类时，A 就对B 产生了依赖，这是概念上的描述。那么如何在项目中以依赖的方式引入一个我们需要的jar 包呢？
答案非常简单，就是使用dependency 标签指定被依赖jar 包的坐标就可以了。

<dependency>
<groupId>com.atguigu.maven</groupId>
<artifactId>Hello</artifactId>
<version>0.0.1-SNAPSHOT</version>
<scope>compile</scope>
</dependency>

对于我们自己开发的Maven工程，要使用 mvn install 命令安装后就可以进入仓库。

依赖的范围

依赖的范围有几个可选值，常用：compile、test、provided。

从项目结构角度理解compile和test的区别

maven4

compile范围依赖

对主程序是否有效：有效
对测试程序是否有效：有效
是否参与打包：参与
是否参与部署：参与
典型例子：spring-core

test范围依赖

对主程序是否有效：无效
对测试程序是否有效：有效
是否参与打包：不参与
是否参与部署：不参与
典型例子：Junit

从开发和运行这两个不同阶段理解compile 和provided 的区别

maven5

provided范围依赖

对主程序是否有效：有效
对测试程序是否有效：有效
是否参与打包：不参与
是否参与部署：不参与
典型例子：Servlet-api.jar

有效性总结

| | compile | test | provided |
| - | - | - | - |
| 主程序 | √ | × | √ |
| 测试程序 | √ | √ | √ |
| 参与部署 | √ | × | × |

依赖的传递性

A 依赖B，B 依赖C，A 能否使用C 呢？那要看B 依赖C 的范围是不是compile，如果是则可用，否则不可用。

maven6

依赖的排除

如果我们在当前工程中引入了一个依赖是A，而A 又依赖了B，那么Maven 会自动将A 依赖的B 引入当前工程，但是个别情况下B 有可能是一个不稳定版，或对当前工程有不良影响。这时我们可以在引入A 的时候将B 排除。

配置方式

<dependency>
<groupId>com.atguigu.maven</groupId>
<artifactId>HelloFriend</artifactId>
<version>0.0.1-SNAPSHOT</version>
<type>jar</type>
<scope>compile</scope>
<exclusions>
    < exclusion>
        <groupId>commons-logging</groupId>
        <artifactId>commons-logging</artifactId>
    </ exclusion> 
</exclusions>
</dependency>

统一管理所依赖

.jar 包的版本对同一个框架的一组jar包最好使用相同的版本。为了方便升级架构，可以将jar包的版本信息统一提取出来

统一声明版本号
```
<properties>
<atguigu.spring.version>4.1.1.RELEASE</atguigu.spring.version>
</properties>
```
- 其中atguigu.spring.version 部分是自定义标签。
- 可以在任何需要统一声明后再引用的场合都可以使用properties标签

引用前面声明的版本号

<dependencies>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-core</artifactId>
<version>${atguigu.spring.version}</version>
</dependency>
……
</dependencies>

其他用法

<properties>
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
</properties>

依赖的原则

解决jar包冲突

maven7

生命周期

Maven 生命周期定义了各个构建环节的执行顺序，有了这个清单，Maven 就可以自动化的执行构建命令了。
各个构建环节执行的顺序：不能打乱顺序，必须按照既定的正确顺序来执行。
Maven的核心程序中定义了抽象的生命周期，生命周期中各个阶段的具体任务是由插件来完成的。
Maven核心程序为了更好的实现自动化构建，按照这一特点执行生命周期中各个阶段：不论现在要执行生命周期中的哪一阶段，都是从这个生命周期最初的位置开始执行
Maven 有三套相互独立的生命周期，分别是：

Clean Lifecycle 在进行真正的构建之前进行一些清理工作。
Default Lifecycle 构建的核心部分，编译，测试，打包，安装，部署等等。
Site Lifecycle 生成项目报告，站点，发布站点。

它们是相互独立的，你可以仅仅调用clean 来清理工作目录，仅仅调用site 来生成站点。当然你也可以直接运行 mvn clean install site 运行所有这三套生命周期。
每套生命周期都由一组阶段(Phase)组成，我们平时在命令行输入的命令总会对应于一个特定的阶段。比如，运行mvn clean，这个clean 是Clean 生命周期的一个阶段。有Clean 生命周期，也有clean 阶段。

Clean 生命周期

Clean 生命周期一共包含了三个阶段：
pre-clean 执行一些需要在clean 之前完成的工作
clean 移除所有上一次构建生成的文件
post-clean 执行一些需要在clean 之后立刻完成的工作

Site 生命周期

pre-site 执行一些需要在生成站点文档之前完成的工作
site 生成项目的站点文档
post-site 执行一些需要在生成站点文档之后完成的工作，并且为部署做准备
site-deploy 将生成的站点文档部署到特定的服务器上
这里经常用到的是site 阶段和site-deploy 阶段，用以生成和发布Maven 站点，这可是Maven 相当强大
的功能，Manager 比较喜欢，文档及统计数据自动生成，很好看。

Default 生命周期

Default 生命周期是Maven 生命周期中最重要的一个，绝大部分工作都发生在这个生命周期中。这里，
只解释一些比较重要和常用的阶段：
validate
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。
pre-integration-test
integration-test
post-integration-test
verify
install 将包安装至本地仓库，以让其它项目依赖。
deploy 将最终的包复制到远程的仓库，以让其它开发人员与项目共享或部署到服务器上运行。

生命周期与自动化构建

运行任何一个阶段的时候，它前面的所有阶段都会被运行，例如我们运行mvn install 的时候，代码会被编译，测试，打包。这就是Maven 为什么能够自动执行构建过程的各个环节的原因。此外，Maven 的插件机制是完全依赖Maven 的生命周期的，因此理解生命周期至关重要。

插件和目标

Maven 的核心仅仅定义了抽象的生命周期，具体的任务都是交由插件完成的。
每个插件都能实现多个功能，每个功能就是一个插件目标。
Maven 的生命周期与插件目标相互绑定，以完成某个具体的构建任务。

例如：compile 就是插件maven-compiler-plugin 的一个目标；pre-clean 是插件maven-clean-plugin 的一个目标。

配置eclipse中的Maven

Maven插件的设置： Window->Preferences->Maven

installations : 指定Maven核心程序的位置。默认是插件自带的Maven程序，改为我们自己解压的那个。
user settings : 指定Maven核心程序中 conf/settings.xml 文件的位置，进而获取本地仓库的位置。

执行Maven命令：选中pom.xml 右键 Run As->Maven build…->Goals->输入 compile ->点击 run

  <profile>
      <id>jdk-1.7</id>
      <activation>
          <activeByDefault>true</activeByDefault>
          <jdk>1.7</jdk>
      </activation>
      <properties>
          <maven.compiler.source>1.7</maven.compiler.source>
          <maven.compiler.target>1.7</maven.compiler.target>
          <maven.compiler.compilerVersion>1.7</maven.compiler.compilerVersion>
      </properties>
  </profile>

继承

现状：由于test范围的依赖不能传递，所以必然会分散在各个模块工程中，很容易造成版本不一致。
需求：统一管理各个模块工程中对Junit依赖的版本。
解决思路：将Junit依赖统一提取到“父”工程中，在子工程中声明Junit依赖是不指定版本，以父工程中统一设定的为准。同时也便于修改。
操作步骤：

创建一个Maven工程作为父工程。注意：打包方式为pom
在子工程中声明对父工程的引用
将子工程的坐标中与父工程坐标中重复的内容删除
在父工程中统一管理Junit的依赖
在子工程中删除Junit依赖的版本号部分

注意：配置集成后，执行安装命令时要先安装父工程。
聚合
目的：将多个工程拆分为模块后，需要手动逐个安装到仓库后依赖才能够生效。修改源码后也需要逐个手动进行clean 操作。而使用了聚合之后就可以批量进行Maven 工程的安装、清理工作。
配置
在总的聚合工程中使用modules/module 标签组合，指定模块工程的相对路径即可

<modules>
<module>../Hello</module>
<module>../HelloFriend</module>
<module>../MakeFriends</module>
</modules>


## MavenWeb工程的自动部署

配置后执行 `mvn deploy`命令

## 搜索依赖信息

http://mvnrepository.com/

---

参考链接：

* https://www.bilibili.com/video/BV1Pt411y7Rh
* https://blog.csdn.net/zxm1306192988/article/details/76209062
* https://www.runoob.com/maven

版权属于：moluuser
本文链接：https://moluuser.com/archives/29/

本作品采用知识共享署名-非商业性使用-相同方式共享 4.0 国际许可协议进行许可。

正文到此结束

扫一扫在手机打开当前页

【我要纠错】

发表评论取消回复

评论 *

私密评论

名称 *

邮箱 *

地址

左手G
这个，直接是一本书啊架势啊你用什么软件写的这篇文章，图文并茂
22攻略
非常感谢你分享这篇文章，我从中学到了很多新的知识。
蓝天
老哥，备份发邮件的时候出现SMTP write error: ...
luo
nb,感谢分享，还想请教一下这种网页博客怎么做出来的？我也想整...
Ply
这是万维考试系统吧，请问大佬搞出什么具体实现了吗我这边想练习...

杭州《台风》
浏览次数: 2092
C#获取句柄文本框信息及鼠标控制
浏览次数: 4061
lcof刷题记录(C++)
浏览次数: 2237
Apache2.x配置SSL证书及开启HSTS
浏览次数: 3347
MyBatis
浏览次数: 2934

Maven 笔记

moluuser • 2020 年 05 月 01 日

开发项目所用技术

maven1

存在问题

一个项目就是一个工程
- 如果项目庞大，就不适合用package划分模块，最好一个模块对应一个工程，利于分工。
- 借助Maven就可以把一个项目拆分成多个工程。
项目中所需jar包必须手动导入到WEB-INF/lib目录下
- 同样的jar包重复出现在不同工程中，造成存储空间浪费，工程臃肿。
- 借助Maven，可以将jar包保存在仓库中，需要jar包的工程只需以坐标方式引用即可。
第三方jar包
- 使用Maven 我们可以享受到一个完全统一规范的jar 包管理体系。你只需要在你的项目中以坐标的方式依赖一个jar 包，Maven 就会自动从中央仓库进行下载，并同时下载这个jar 包所依赖的其他jar 包。
jar包之间的依赖
- Maven 就可以替我们自动的将当前jar 包所依赖的其他所有jar 包全部导入进来，无需人工参与，节约了我们大量的时间和精力。

Maven简介

Maven 是Apache 软件基金会组织维护的一款自动化构建工具，专注服务于Java 平台的项目构建和依赖管理。Maven 这个单词的本意是：专家，内行。读音是['meɪv(ə)n]或['mevn]。
构建过程的几个主要环节

自动化构建：Maven可以自动的从构建过程的起点一直执行到终点

安装Maven

解压Maven核心程序的压缩包，放在一个非中文、无空格的路径下。
配置Maven相关的环境变量
1. MAVEN_HOME 或 M2_HOME变量值为Maven路径 D:\uninstallapp\apache-maven-3.6.3
2. Path 追加
  变量值为 D:\uninstallapp\apache-maven-3.6.3\bin
验证 mvn -v

Maven核心概念

Maven 能够实现自动化构建是和它的内部原理分不开的，这里我们从Maven 的九个核心概念入手，看看Maven 是如何实现自动化构建的。

①POM
②约定的目录结构
③坐标
④依赖管理
⑤仓库管理
⑥生命周期
⑦插件和目标
⑧继承
⑨聚合

约定的目录结构

maven2

我们在开发中如果需要让第三方工具或框架知道我们自己创建的资源在哪，那么基本上就是两种方式：

通过配置的形式
基于第三方工具或框架的约定

        Hello
        |---src
        |---|---main
        |---|---|---java
        |---|---|---resources
        |---|---test
        |---|---|---java
        |---|---|---resources
        |---pom.xml

Maven常用命令

执行与构建过程相关的Maven命令，必须进入pom.xml 所在的目录。
常用命令：
1. mvn clean : 清理
2. mvn compile : 编译主程序
3. mvn test-compile : 编译测试程序
4. mvn test : 执行测试
5. mvn package : 打包
6. mvn install ：安装
7. mvn site ：生成站点

坐标

使用如下三个向量在Maven 的仓库中唯一的确定一个Maven 工程。

groupid：公司或组织的域名倒序+当前项目名称
artifactId：当前项目的模块名称
version：当前模块的版本

<project xmlns = "http://maven.apache.org/POM/4.0.0"
    xmlns:xsi = "http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation = "http://maven.apache.org/POM/4.0.0
    http://maven.apache.org/xsd/maven-4.0.0.xsd">
 
    <!-- 模型版本 -->
    <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</version>
</project>

Maven 工程的坐标与仓库中路径的对应关系

如何通过坐标到仓库中查找jar 包？

将gav 三个向量连起来com.atguigu.maven+Hello+0.0.1-SNAPSHOT
以连起来的字符串作为目录结构到仓库中查找
com/atguigu/maven/Hello/0.0.1-SNAPSHOT/Hello-0.0.1-SNAPSHOT.jar

注意：我们自己的Maven 工程必须执行安装操作才会进入仓库。安装的命令是：mvn install

仓库

maven3

仓库中的文件

Maven 的插件
我们自己开发的项目的模块
第三方框架或工具的jar 包

不管是什么样的jar 包，在仓库中都是按照坐标生成目录结构，所以可以通过统一的方式查询或依赖。

依赖

依赖的目的

<dependency>
<groupId>com.atguigu.maven</groupId>
<artifactId>Hello</artifactId>
<version>0.0.1-SNAPSHOT</version>
<scope>compile</scope>
</dependency>

对于我们自己开发的Maven工程，要使用 mvn install 命令安装后就可以进入仓库。

依赖的范围

依赖的范围有几个可选值，常用：compile、test、provided。

从项目结构角度理解compile和test的区别

maven4

compile范围依赖

对主程序是否有效：有效
对测试程序是否有效：有效
是否参与打包：参与
是否参与部署：参与
典型例子：spring-core

test范围依赖

对主程序是否有效：无效
对测试程序是否有效：有效
是否参与打包：不参与
是否参与部署：不参与
典型例子：Junit

从开发和运行这两个不同阶段理解compile 和provided 的区别

maven5

provided范围依赖

对主程序是否有效：有效
对测试程序是否有效：有效
是否参与打包：不参与
是否参与部署：不参与
典型例子：Servlet-api.jar

有效性总结

| | compile | test | provided |
| - | - | - | - |
| 主程序 | √ | × | √ |
| 测试程序 | √ | √ | √ |
| 参与部署 | √ | × | × |

依赖的传递性

A 依赖B，B 依赖C，A 能否使用C 呢？那要看B 依赖C 的范围是不是compile，如果是则可用，否则不可用。

maven6

依赖的排除

配置方式

<dependency>
<groupId>com.atguigu.maven</groupId>
<artifactId>HelloFriend</artifactId>
<version>0.0.1-SNAPSHOT</version>
<type>jar</type>
<scope>compile</scope>
<exclusions>
    < exclusion>
        <groupId>commons-logging</groupId>
        <artifactId>commons-logging</artifactId>
    </ exclusion> 
</exclusions>
</dependency>

统一管理所依赖

.jar 包的版本对同一个框架的一组jar包最好使用相同的版本。为了方便升级架构，可以将jar包的版本信息统一提取出来

统一声明版本号
```
<properties>
<atguigu.spring.version>4.1.1.RELEASE</atguigu.spring.version>
</properties>
```
- 其中atguigu.spring.version 部分是自定义标签。
- 可以在任何需要统一声明后再引用的场合都可以使用properties标签

引用前面声明的版本号

<dependencies>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-core</artifactId>
<version>${atguigu.spring.version}</version>
</dependency>
……
</dependencies>

其他用法

<properties>
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
</properties>

依赖的原则

解决jar包冲突

maven7

生命周期

Maven 生命周期定义了各个构建环节的执行顺序，有了这个清单，Maven 就可以自动化的执行构建命令了。
各个构建环节执行的顺序：不能打乱顺序，必须按照既定的正确顺序来执行。
Maven的核心程序中定义了抽象的生命周期，生命周期中各个阶段的具体任务是由插件来完成的。
Maven核心程序为了更好的实现自动化构建，按照这一特点执行生命周期中各个阶段：不论现在要执行生命周期中的哪一阶段，都是从这个生命周期最初的位置开始执行
Maven 有三套相互独立的生命周期，分别是：

Clean Lifecycle 在进行真正的构建之前进行一些清理工作。
Default Lifecycle 构建的核心部分，编译，测试，打包，安装，部署等等。
Site Lifecycle 生成项目报告，站点，发布站点。

它们是相互独立的，你可以仅仅调用clean 来清理工作目录，仅仅调用site 来生成站点。当然你也可以直接运行 mvn clean install site 运行所有这三套生命周期。
每套生命周期都由一组阶段(Phase)组成，我们平时在命令行输入的命令总会对应于一个特定的阶段。比如，运行mvn clean，这个clean 是Clean 生命周期的一个阶段。有Clean 生命周期，也有clean 阶段。

Clean 生命周期

Clean 生命周期一共包含了三个阶段：
pre-clean 执行一些需要在clean 之前完成的工作
clean 移除所有上一次构建生成的文件
post-clean 执行一些需要在clean 之后立刻完成的工作

Site 生命周期

pre-site 执行一些需要在生成站点文档之前完成的工作
site 生成项目的站点文档
post-site 执行一些需要在生成站点文档之后完成的工作，并且为部署做准备
site-deploy 将生成的站点文档部署到特定的服务器上
这里经常用到的是site 阶段和site-deploy 阶段，用以生成和发布Maven 站点，这可是Maven 相当强大
的功能，Manager 比较喜欢，文档及统计数据自动生成，很好看。

Default 生命周期

Default 生命周期是Maven 生命周期中最重要的一个，绝大部分工作都发生在这个生命周期中。这里，
只解释一些比较重要和常用的阶段：
validate
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。
pre-integration-test
integration-test
post-integration-test
verify
install 将包安装至本地仓库，以让其它项目依赖。
deploy 将最终的包复制到远程的仓库，以让其它开发人员与项目共享或部署到服务器上运行。

生命周期与自动化构建

插件和目标

Maven 的核心仅仅定义了抽象的生命周期，具体的任务都是交由插件完成的。
每个插件都能实现多个功能，每个功能就是一个插件目标。
Maven 的生命周期与插件目标相互绑定，以完成某个具体的构建任务。

例如：compile 就是插件maven-compiler-plugin 的一个目标；pre-clean 是插件maven-clean-plugin 的一个目标。

配置eclipse中的Maven

Maven插件的设置： Window->Preferences->Maven

installations : 指定Maven核心程序的位置。默认是插件自带的Maven程序，改为我们自己解压的那个。
user settings : 指定Maven核心程序中 conf/settings.xml 文件的位置，进而获取本地仓库的位置。

执行Maven命令：选中pom.xml 右键 Run As->Maven build…->Goals->输入 compile ->点击 run

  <profile>
      <id>jdk-1.7</id>
      <activation>
          <activeByDefault>true</activeByDefault>
          <jdk>1.7</jdk>
      </activation>
      <properties>
          <maven.compiler.source>1.7</maven.compiler.source>
          <maven.compiler.target>1.7</maven.compiler.target>
          <maven.compiler.compilerVersion>1.7</maven.compiler.compilerVersion>
      </properties>
  </profile>

继承

现状：由于test范围的依赖不能传递，所以必然会分散在各个模块工程中，很容易造成版本不一致。
需求：统一管理各个模块工程中对Junit依赖的版本。
解决思路：将Junit依赖统一提取到“父”工程中，在子工程中声明Junit依赖是不指定版本，以父工程中统一设定的为准。同时也便于修改。
操作步骤：

创建一个Maven工程作为父工程。注意：打包方式为pom
在子工程中声明对父工程的引用
将子工程的坐标中与父工程坐标中重复的内容删除
在父工程中统一管理Junit的依赖
在子工程中删除Junit依赖的版本号部分

注意：配置集成后，执行安装命令时要先安装父工程。
聚合
目的：将多个工程拆分为模块后，需要手动逐个安装到仓库后依赖才能够生效。修改源码后也需要逐个手动进行clean 操作。而使用了聚合之后就可以批量进行Maven 工程的安装、清理工作。
配置
在总的聚合工程中使用modules/module 标签组合，指定模块工程的相对路径即可

<modules>
<module>../Hello</module>
<module>../HelloFriend</module>
<module>../MakeFriends</module>
</modules>


## MavenWeb工程的自动部署

配置后执行 `mvn deploy`命令

## 搜索依赖信息

http://mvnrepository.com/

---

参考链接：

* https://www.bilibili.com/video/BV1Pt411y7Rh
* https://blog.csdn.net/zxm1306192988/article/details/76209062
* https://www.runoob.com/maven

版权属于：moluuser
本文链接：https://moluuser.com/archives/29/

本作品采用知识共享署名-非商业性使用-相同方式共享 4.0 国际许可协议进行许可。

开发项目所用技术

存在问题

Maven简介

安装Maven

Maven核心概念

约定的目录结构

Maven常用命令

坐标

仓库

分类

仓库中的文件

依赖

依赖的目的

依赖的范围

从项目结构角度理解compile和test的区别

从开发和运行这两个不同阶段理解compile 和provided 的区别

有效性总结

依赖的传递性

依赖的排除

统一管理所依赖

依赖的原则

生命周期

Clean 生命周期

Site 生命周期

Default 生命周期

生命周期与自动化构建

插件和目标

配置eclipse中的Maven

继承

聚合

发表评论 取消回复

Maven 笔记

开发项目所用技术

存在问题

Maven简介

安装Maven

Maven核心概念

约定的目录结构

Maven常用命令

坐标

仓库

分类

仓库中的文件

依赖

依赖的目的

依赖的范围

从项目结构角度理解compile和test的区别

从开发和运行这两个不同阶段理解compile 和provided 的区别

有效性总结

依赖的传递性

依赖的排除

统一管理所依赖

依赖的原则

生命周期

Clean 生命周期

Site 生命周期

Default 生命周期

生命周期与自动化构建

插件和目标

配置eclipse中的Maven

继承

聚合

发表评论取消回复