目前的技术在开发中存在的问题

  1. 一个项目就是一个工程
    1. 如果一个项目非常庞大，就不适合继续使用package来划分模块。最好是每一个模块对应一个工程，利于分工协作。借助于Maven就可以将一个项目分成多个工程。
  2. 项目中需要的jar包必须手动“复制”、“粘贴”到WEB-INF/lib目录下
  3. jar包需要别人替我们准备好，或到官网下载
  4. 一个jar包依赖的其他jar包需要自己手动加入到项目中

安装Maven核心程序

  1. 检查JAVA_HOME环境变量
    命令行输入 echo %JAVA_HOME%

  2. 解压Maven核心程序的压缩包，放在一个非中文无空格的路径下

  3. 配置Maven相关的环境变量

    1. MAVEN_HOME或M2_HOME（为了向下兼容，避免一些问题）
      • 一般HOME的环境变量都是bin目录的上一级,path是带bin目录的
    2. path

  4. 验证：运行mvn -v 查看Maven版本

  5. Maven的核心概念

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

  6. 第一个Maven工程

    1. 创建预定的目录结构
      • 根目录（工程名）
        • src （源码）
          • main （存放主程序）
            • java （存放Java源文件）
            • resources （存放框架或其他工具的配置文件）
          • test （存放测试程序）
            • java（存放Java源文件）
            • resources （存放框架或其他工具的配置文）
        • pom.xml （Maven工程的核心配置文件）
    2. 为什么要遵守约定的目录结构
      • Maven要负责项目的自动化构建，它必须知道文件保存在哪
      • 如果自己定义的东西想让框架或工具知道，有两种方法：
        • 以配置的方式明确告诉框架
        • 遵守框架内部已存在的约定
      • 约定 > 配置 > 编码

  7. 常用Maven命令

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

  8. 关于联网问题

    1. Maven的核心程序中仅仅定义了抽象的生命周期，但具体的工作必须由特定的插件来完成。而插件本身并不包含在Maven的核心程序中。
    2. 当我们执行的Maven命令需要用到某些插件时，Maven核心程序会首先到本地仓库中查找。
      • 本地仓库的默认位置：[系统中当前用户的家目录].m2\repository
        C:\Users[登录当前系统的用户名].m2\repository
    3. Maven核心程序如果在本地仓库中找不到需要的插件，那么它会自动连接外网，到中央仓库下载。如果无法连接外网，则构建失败。
    4. 修改本地仓库的默认位 置：
      1. 找到Maven解压目录\conf\settings.xml
      2. 在settings.xml文件中找到localRepository标签
      3. 将/path/to/local/repo从注释中取出
      4. 将标签体内容修改： E:\app\aboutJava\maven\RepMaven

  9. POM

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

  10. 坐标

    1. 数学中的坐标：
      1. 在平面上，使用X、Y两个向量可以唯一的定位平面中的任何一个点。
      2. 在空间上，使用X、Y、Z三个向量可以唯一的定位空间中的任何一个点。
    2. Maven中的坐标
      使用下面三个向量在仓库中唯一定位一个Maven工程
      1. groupId：公司或组织域名倒序+项目名
        • com.atguigu.maven
      2. artifactId：
        • Hello
      3. version
        • 1.0.0
    3. Maven工程的坐标与仓库中路径的对应关系
      • 坐标：
        org.springframework
        spring-core
        4.0.0.RELEASE
      • 路径：
        org/springframework/spring-core/4.0.0.RELEASE/spring-core-4.0.0.RELEASE.jar

  11. 仓库

    1. 仓库的分类：
      1. 本地仓库：当前电脑上部署的仓库目录，为当前电脑上所有的Maven工程服务
      2. 远程仓库
        1. 私服：搭建在局域网环境中，为局域网范围内的所有Maven工程服务
        2. 中央仓库：架设在Internet上，为全世界所有Maven工程服务
        3. 中央仓库镜像：为了分担中央仓库流量，提升用户访问速度
    2. 仓库中保存的内容：Maven工程
      1. Maven自身所需要的插件
      2. 第三方框架或工具的jar包
      3. 我们自己开发的Maven工程

  12. 依赖[初步]

    1. Maven解析依赖信息时会到本地仓库中查找被依赖的jar包。
      • 对于我们自己开发的Maven工程，使用mvn install 命令安装后就可以j进入仓库。
    2. 依赖的常用范围
      1. compile范围
        • 对主程序是否有效： 有效
        • 对测试程序是否有效： 有效
        • 是否参与打包： 参与
        • 是否参与部署：参与
        • 典型例子：spring-core
      2. test范围
        • 对主程序是否有效： 无效
        • 对测试程序是否有效： 有效
        • 是否参与打包：不参与
        • 是否参与部署：不参与
        • 典型例子：junit
      3. provided范围（用在Web工程）
        • 对主程序是否有效：有效
        • 对测试程序是否有效：有效
        • 是否参与打包：不参与
        • 是否参与部署：不参与
        • 典型例子：servlet-api.jar

  13. 生命周期

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

  1. 在Eclipse中使用Maven

    1. Maven插件：Eclipse内置
    2. Maven插件的设置
      1. Installations：指定Maven核心程序的位置。不建议使用插件自带的Maven程序，而应该使用我们自己解压的那个。
      2. user settings：指定conf/settings.xml的指定位置，进而获取本地仓库的位置。
    3. 基本操作
      1. 创建Maven版的Java工程
      2. 创建Maven版的Web工程
      3. 执行Maven命令

  2. 依赖[高级]

    1. 依赖的传递性
      1. 好处：可以传递的依赖不必在每个模块工程中都重复声明，在“最下面”的工程中依赖一次即可。
      2. 注意：非compile范围的依赖不能传递。所以在各个工程模块中，如果有需要就得重复声明依赖。
    2. 依赖的排除
      • 依赖排除的配置方式