maven

在使用maven前

2.项目中需要的jar包必须手动赋值，粘贴到WEB-INF/lib目录下

　　带来的问题是：同样的jar包文件重复出现在不同的项目工程中，一方面浪费存储空间，另外也让工程比较臃肿。

　　借助Maven，可以将jar包仅仅保存在仓库中，有需要使用的工程引用这个文件接口，并不需要真的把jar包复制过来。

3.jar包需要别人替我们准备好，或到官网下载。

　　不同技术的官网提供jar包下载的形式是五花八门的。

　　有些技术的官网就是通过Maven或SVN等专门的工具来提供下载的。

　　如果是以不规范的方式下载的jar包，那么其中的内容很可能也是不规范的

　　借助于Maven可以以一种规范的方式下载jar包，因为所有知名框架或第三方工具的jar包以及按照统一的规范放在了Maven的中央仓库中。

　　以规范的方式下载的jar包，内容也是可靠的。

 

4.一个jar包依赖的其它jar包需要自己手动加入到项目中

　　如果所有jar包之间的依赖关系都需要程序员自己非常清楚的了解，那么就会极大的增加学习成本。

　　Maven会自动将被依赖的jar包导入进来。

Maven是什么

　　Maven是一款服务于Java平台的自动化构建工具。Maven本身也是Java写的。

1. Make->Ant->Maven->Gradle     (Gradle比maven要好)
2. 构建
   1. 概念：以“Java源文件”，"框架配置文件"。“JSP”，“HTML”，“图片”等资源为“原材料”，去“生产”一个可以运行的项目的过程
      • 编译
      • 部署
      • 搭建
   2. 编译：java源文件-》编译-》Class字节码文件-》交给JVM去执行
   3. 部署：一个BS项目最终运行的并不是动态Web工程本身，而是这个动态Web工程“编译的结果”　　
      1. 　　生的鸡-》处理-》熟的鸡
      2. 动态Web工程-》编译，部署-》编译结果

src是源码目录（Java文件）

build是class文件

运行时环境：JRE System Liabrary  Apche tomcat    其实是一组jar包的引用，并没有把jar包本身复制到工程中，所以并不是目录

eclipse的双向箭头，定位文件位置

没有tomcat，就不能建jsp文件（会报错）

真正运行的是编译结果，不是web工程本身。开发过程中，所有的路径或配置文件中配置的类路径等都是以编译结果的目录结构为标准的。

QA：质量保证

什么是构建

• 构建过程中的各个环节
  • 清理：将以前编译得到的旧的class字节码文件删除，为下一次编译做准备
  • 编译：将Java源程序编程成class字节码文件
  • 测试：自动测试，自动调用junit程序
  • 报告： 测试程序执行的结果
  • 打包：动态Web工程打war包，Java工程打jar包
  • 安装：将打包得到的文件复制到仓库中的指定位置
  • 部署：将动态Web工程生成的war包复制到servlet容器指定目录下，使其可以运行
• 自动化构建

安装Maven核心程序

home路径一般是bin的上一级，path路径一般包含到bin目录

其实在配置环境变量的时候，可以在用户变量那里配置，（）以往都在系统变量那里配置，因为我们几乎是不会换用户的，所以系统环境变量约等于用户环境变量。而系统环境变量有一些变量，要是不小心删掉了很不好，所以有时候在用户环境变量里配置比较好。

 

 

Maven的核心概念

• 约定的目录结构
• POM
• 坐标
• 依赖
• 仓库
• 生命周期/插件/目标
• 继承
• 聚合

第一个maven工程

• 创建约定的目录结构
  • 根目录：工程名
  • src目录：源码
  • pom.xml文件：Maven工程的核心配置文件
  • main目录：存放主程序
  • test目录：存放测试程序
  • java目录：存放java源文件
  • resources目录：存放框架或其它工具的配置文件
• 为什么要遵守约定的目录结构呢？
  • Maven要负责我们这个项目的自动化构建，以编译为例，Maven要想自动进行编译，那么他必须知道Java源文件保存在哪里。
  • 如果我自己自定义的东西想要让框架或工具知道
    • 以配置的方式明确告诉框架
    • 遵守框架内部已经存在的约定
  • 约定>配置>编码

 常用Maven命令

• 注意：执行与构建过程相关的Maven命令，必须进入pom.xml所在的目录。
  • 与构建过程相关：编译，测试，打包
  • 常用命令
    • mvn clean：清理
    • mvn compile：编译主程序
    • mvn test-compile：编译测试程序
    • mvn test：执行测试
    • mvn package：打包

关于联网问题

• Maven的核心程序中仅仅定义了抽象的生命周期，但是具体的工作必须由特定的插件来完成。而插件本身并不包含在Maven的核心程序中。当我们执行的核心程序中。
• 当我们执行的Maven命令需要用到某些插件时，Maven核心程序会首先到本地仓库中查找。
• 本地仓库的默认位置：[系统中当前用户的目录]\.m2\repository
• Maven核心程序如果在本地仓库中找不到需要的插件，那么它会自动连接外网，到中央仓库下载。
• 如果此时无法连接外网，则构建失败。
• 修改默认本地仓库的位置可以让Maven核心程序到我们事先准备好的目录下查找插件

compile作用是：生成target\classes

test-compile作用是：生成target\test-classes

packaging:生成target\maven-archiver，target\surefire-reports，target\打包文件

clean：把上面生成的清理掉

 

POM

• 含义：Project Object Model项目对象模型
  • Dom  Document Object Model文档对象模型
• pom.xml对于maven工程是核心配置文件，与构建过程相关的一切设置都在这个文件中进行配置。
  • 重要程度相当于web.xml对于动态Web工程

gav：groupid（公司或组织域名倒叙+项目名） artifactid（模块名） version（版本）

仓库：

• 仓库的分类
  • 本地仓库：当前电脑上部署的仓库目录，为当前电脑上所有Maven工程服务
  • 远程仓库
    • 私服：搭建在局域网环境中
    • 中央仓库
    • 中央仓库镜像

SNAPSHOT：快照

依赖

• Maven解析依赖信息是会到本地仓库中查找被依赖的jar包
  • 对于我们自己开发的Maven工程，使用mvn install命令安装后就可以进入仓库　　

Maven依赖的范围（scope）

• 对主程序是否有效
• 对测试程序是否有效
• 是否参与打包

Maven生命周期

• 各个构建环节执行的顺序：不能打乱顺序，必须按照既定的正确顺序来执行。
• Maven的核心程序中定义了抽象的生命周期，生命周期中各个阶段的具体任务是由插件来完成的。
• Maven核心程序为了更好的实现自动化构建，按照这一特点执行生命周期中的·各个阶段：不论要执行生命周期的哪一个阶段，都要从这个生命周期最初的位置开始执行。
• 插件和目标
  • 生命周期的各个阶段仅仅定义了要执行的任务是什么
  • 各个阶段和插件的目标是对应的
  • 相似的目标由特定的插件来完成
  • 可以将目标看做 “调用插件功能的命令”

Eclipse中执行Maven命令：选中pom.xml，右键 run as，就提供了很多maven命令

依赖

• 依赖的传递性
  • 好处：可以传递的依赖不必在每个模块中都重复声明,在“最下面”的工程中依赖一次就可以
  • 注意：非compile范围的依赖不能传递。所以在各个工程模块中，如果有需要就得重复声明依赖
• 依赖的排除
  • 需要设置依赖排除的场合：不稳定jar包，不希望加入当前工程
  • 依赖排除的设置方式
    • 依赖的排除也具有传递性

<exclusions>
<exclusion>
<groupId>commons-logging</groupId>
<artifactId>commons-logging</artifactId>
</exclusion>
</exclusions>

• 依赖的原则说明
  • 作用：解决模块工程之间的jar包冲突
  • 验证路径最短者优先原则
  • 验证路径相同时先声明者优先
    • 先声明指的是dependency标签的声明顺序

统一管理依赖的版本号

• 建议配置方式
  • 使用properties标签内使用自定义标签统一声明版本号
  •  在需要统一版本的位置，

• 注意：配置继承后执行安装命令，要先安装父工程

聚合：

• 作用：一键安装各个模块工程
• 配置方式：在一个总的聚合工程中，配置参与聚合的各个模块
• 使用方式：