Maven简介及其主要概念

Maven简介

Maven是什么?

1.Maven是Apache软件基金会组织维护的一款自动化构建工具，专注服务于平台的项目构建和依赖管理。
2.构建:就是以我们编写的代码、框架配置文件、国际化。
优点：

优点一：项目非常大时，可借助Maven将一个项目拆分成多个工程，最好是一个模块对应一个工程，利于分工协作。而且模块之间还是可以发送消息的。
优点二：借助Maven，可将jar包仅仅保存在“仓库”中，有需要该文件时，就引用该文件接口，不需要复制文件过来占用空间。
优点三：借助Maven可以以规范的方式下载jar包，因为所有的知名框架或第三方工具的jar包已经按照统一的规范存放到了Maven的中央仓库中。
优点四：Maven会自动将你要加入到项目中的jar包导入，不仅导入，而且还会将该jar包所依赖的jar包都自动导入进来。而且是导入该包的最新版本

构建的过程中的环节

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

1：清理：删除以前的编译结果，为重新编译做准备
2：编译：将java源程序编译为字节码的文件
3：测试：针对项目中的关键点进行测试，确保项目在迭代开发中关键点的正确性。
4：报告：将每一次测试后以标准的格式化记录和展示测试的结果
5：打包：讲一个包含结构文件的额工程封装为一个压缩文件，用于安装或者部署，java工程对应jar包、web工程对应war包。
6：安装：在Maven环境下特指将打包的结果–jar包或者war包安装到本地的仓库中。
7：部署：将打包的结果部署到远程仓库或者war包部署到服务器上运行。

Maven的核心概念

• 1.约定的结构目录
• 2.POM（终点）
• 3.坐标
• 4.依赖
• 5.仓库
• 6.生命周期/插件/目标
• 7.继承
• 8.聚合

约定的结构目录

　　　　[1] 根目录：工程名
　　　　[2] |---src：源码
　　　　[3] |---|---main:存放主程序
　　　　[4] |---|---|---java：java源码文件
　　　　[5] |---|---|---resource：存放框架的配置文件
　　　　[6] |---|---test：存放测试程序
　　　　[7] |---pop.xml：maven的核心配置文件

• 根目录：工程名
• src目录：源码
• pom.xml文件： Maven工程的核心配置文件
• main目录：存放主程序
• test目录： 存放测试程序
• java目录： 存放java源文件
• resources目录： 存放框架或其他工具的配置文件

为什么要遵守约定的目录结构：

• Maven要负责项目的自动化构建，以编译为例，Maven要想自动进行编译，那么它必须知道java源文件保存在哪里。

常用的Maven命令

#清理生命周期： clean  (把所有生成的东西都删除)
mvn clean:#清理

mvn compile:#编译主程序
#执行mvn compile， 结果是在项目的根目录下生成target目录（结果目录），
#maven编译的java程序，最后的class文件都放在target目录中
#设置本机存放资源的目录位置(设置本机仓库)：
# 1. 修改maven的配置文件， maven安装目录/conf/settings.xml
#    先备份 settings.xml
# 2. 修改 <localRepository>  指定你的目录（不要使用中文目录）
mvn test-compile: #编译测试程序
mvn test:#执行测试
mvn package：#打包
mvn install：#安装
mvn deploy：#将构件包部署到远程仓库

**注意：**在使用命令时必须进入pom.xml所在的文件目录！

重点概念

<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>
  <!-- 坐标 -->
  <groupId>net.csdn.demo</groupId>
  <artifactId>demo</artifactId>
  <version>1.0-SNAPSHOT</version>
  <!-- 打包类型 -->
  <packaging>jar</packaging>
  <!-- 项目名 -->
  <name>demo</name>
  <!-- 官方网站 -->
  <url>http://maven.apache.org</url>

<!-- 项目属性 -->
  <properties>
    <!-- 项目构建时的字符编码集 -->
    <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
  </properties>

  <!-- 依赖： druid gson -->
  <dependencies>
    <!-- 单元测试工具包 -->
    <dependency>
      <groupId>junit</groupId>
      <artifactId>junit</artifactId>
      <version>3.8.1</version>
      <scope>test</scope>
    </dependency>
  </dependencies>
</project>

POM（重点）

1.含义：

• POM：Project Object Model 项目对象模型
• DOM：Document Object Model 文档对象模型

2.pom.xml 对于Maven工程是核心配置文件，与构建过程相关的一切设置都在这个文件中进行配置，重要程度相当于web.xml对于动态web工程。

3.目前我们在Pom中引入了依赖以及当前项目的坐标位置

Maven的坐标

使用下面三个向量在仓库中唯一定位一个Maven工程

• groupid：公司或者组织域名的倒写+项目名

<groupid>net.csdn.maven</groupid>

• artifactid模块名

<artifactid>Hello</artifactid>

• version：版本

<version>1.0</version>

scope依赖

maven解析依赖信息时会到本地仓库中取查找被依赖的jar包

1、对于本地仓库中没有的会去中央仓库去查找maven坐标来获取jar包，获取到jar之后会下载到本地仓库

2、对于中央仓库也找不到依赖的jar包的时候，就会编译失败了

如果依赖的是自己或者团队开发的maven工程，需要先使用install命令把被依赖的maven工程的jar包导入到本地仓库中

举例：再创建第二个maven工程HelloFriend，其中用到了第一个Hello工程里类的sayHello(String name)方法

我们在给HelloFriend项目使用 mvn compile命令进行编译的时候，会提示缺少依赖Hello的jar包。怎么办呢？

到第一个maven工程中执行 mvn install后，你再去看一下本地仓库，你会发现有了Hello项目的jar包

一旦本地仓库有了依赖的maven工程的jar包后，你再到HelloFriend项目中使用 mvn compile命令的时候，可以成功编译

依赖范围的区别：
1、compile，默认值，适用于所有阶段（开发、测试、部署、运行），本jar会一直存在所有阶段。
2、provided，只在开发、测试阶段使用，目的是不让Servlet容器和你本地仓库的jar包冲突 。如servlet.jar。
3、runtime，只在运行时使用，如JDBC驱动，适用运行和测试阶段。
4、test，只在测试时使用，用于编译和运行测试代码。不会随项目发布。
5、system，类似provided，需要显式提供包含依赖的jar，Maven不会在Repository中查找它。

仓库

1.仓库的分类

本地仓库:当前电脑上部署的仓库目录，为当前电脑上所有的Maven工程服务
远程仓库：

• 私服：搭建在局域网环境中，为局域网范围内的所有Maven工程服务
  

• 中央仓库:假设在Internet上，为全世界所有Maven工程服务

• 中央仓库镜像：为分担中央仓库流量，提升用户访问速度。
  1.仓库中保存的内容：Maven 工程

• Maven自身所欲要的插件

• 第三方框架爱或工具的jar包（jdk-我）

• 我们自己开发的Maven工程

生命周期

默认生命周期：校验-初始化-编译-测试-打包-集成测试-安装-部署

validate-initialize-compile-test-package-integrationTest-install-deploy

Clean Lifecycle 在进行真正的构建之前进行一些清理工作。

1、pre-clean  执行一些需要在clean之前完成的工作

2、clean  移除所有上一次构建生成的文件

3、post-clean  执行一些需要在clean之后立刻完成的工作

Default Lifecycle 构建的核心部分，编译，测试，打包，部署等等。

1、validate
2、generate-sources
3、process-sources
4、generate-resources
5、process-resources     复制并处理资源文件，至目标目录，准备打包
6、compile     编译项目的源代码
7、process-classes
8、generate-test-sources
9、process-test-sources
10、generate-test-resources
11、process-test-resources     复制并处理资源文件，至目标测试目录
12、test-compile     编译测试源代码
13、process-test-classes
14、test     使用合适的单元测试框架运行测试。这些测试代码不会被打包或部署
15、prepare-package
16、package     接受编译好的代码，打包成可发布的格式，如 JAR 
17、pre-integration-test
18、integration-test
19、post-integration-test
20、verify
21、install     将包安装至本地仓库，以让其它项目依赖。
22、deploy     将最终的包复制到远程的仓库，以让其它开发人员与项目共享

Site Lifecycle 生成项目报告，站点，发布站点。

1、pre-site 执行一些需要在生成站点文档之前完成的工作
2、site    生成项目的站点文档
3、post-site     执行一些需要在生成站点文档之后完成的工作，并且为部署做准备
4、site-deploy     将生成的站点文档部署到特定的服务器上