Maven

超详细Maven笔记，归纳了Maven工程目录结构、Maven工程的运行、问题处理、异界Maven常用命令等内容知识。

Maven

• 1. Why?
  • 1.1. 真的需要吗？
    • Maven 并不是直接用来辅助编码的，它战斗的岗位并不是以上各层。
      • Maven 是干什么用的？这是很多同学在刚开始接触 Maven 时最大的问题。之所以会提出这个问题，是因为即使不使用 Maven 我们仍然可以进行 B/S 结构项目的开发。从表述层、业务逻辑层到持久化层再到数据库都有成熟的解决方案——不使用 Maven 我们一样可以开发项目啊？
  • 1.2. 究竟为什么？
    • 为什么要使用 Maven？它能帮助我们解决什么问题？
      • 添加第三方 jar 包
        • 在今天的 JavaEE 开发领域，有大量的第三方框架和工具可以供我们使用。要使用这些 jar 包最简单的方法就是复制粘贴到 WEB-INF/lib 目录下。但是这会导致每次创建一个新的工程就需要将 jar 包重复复制到 lib 目录下，从而造成工作区中存在大量重复的文件，让我们的工程显得很臃肿。 而使用 Maven 后每个 jar 包本身只在本地仓库中保存一份，需要 jar 包的工程只需要以坐标的方式 简单的引用一下就可以了。不仅极大的节约了存储空间，让项目更轻巧，更避免了重复文件太多而造成 的混乱。
      • jar 包之间的依赖关系
        • jar 包往往不是孤立存在的，很多 jar 包都需要在其他 jar 包的支持下才能够正常工作，我们称之为jar 包之间的依赖关系。最典型的例子是：commons-fileupload-1.3.jar 依赖于 commons-io-2.0.1.jar，如果没有 IO 包，FileUpload 包就不能正常工作。 那么问题来了，你知道你所使用的所有 jar 包的依赖关系吗？当你拿到一个新的从未使用过的 jar包，你如何得知他需要哪些 jar 包的支持呢？如果不了解这个情况，导入的 jar 包不够，那么现有的程序将不能正常工作。再进一步，当你的项目中需要用到上百个 jar 包时，你还会人为的，手工的逐一确认它们依赖的其他 jar 包吗？这简直是不可想象的。 而引入 Maven 后，Maven 就可以替我们自动的将当前 jar 包所依赖的其他所有 jar 包全部导入进来，无需人工参与，节约了我们大量的时间和精力。用实际例子来说明就是：通过 Maven 导入commons-fileupload-1.3.jar 后，commons-io-2.0.1.jar 会被自动导入，程序员不必了解这个依赖关系。
      • 获取第三方 jar 包
        • JavaEE 开发中需要使用到的 jar 包种类繁多，几乎每个 jar 包在其本身的官网上的获取方式都不尽相同。为了查找一个 jar 包找遍互联网，身心俱疲，没有经历过的人或许体会不到这种折磨。不仅如此，费劲心血找的 jar 包里有的时候并没有你需要的那个类，又或者又同名的类没有你要的方法——以不规 范的方式获取的 jar 包也往往是不规范的。 使用 Maven 我们可以享受到一个完全统一规范的 jar 包管理体系。你只需要在你的项目中以坐标的方式依赖一个 jar 包，Maven 就会自动从中央仓库进行下载，并同时下载这个 jar 包所依赖的其他 jar 包——规范、完整、准确！一次性解决所有问题！ Tips：在这里我们顺便说一下，统一的规范几乎可以说成是程序员的最高信仰。如果没有统一的规范，就意味着每个具体的技术都各自为政，需要以诸多不同的特殊的方式加入到项目中；好不容易加入进来还会和其他技术格格不入，最终受苦的是我们。而任何一个领域的统一规范都能够极大的降低程序员的工作难度，减少工作量。例如：USB 接口可以外接各种设备，如果每个设备都有自己独特的接口，那么不仅制造商需要维护各个接口的设计方案，使用者也需要详细了解每个设备对应的接口，无疑是非常繁琐的。
      • 将项目拆分成多个工程模块
        • 随着 JavaEE 项目的规模越来越庞大，开发团队的规模也与日俱增。一个项目上千人的团队持续开发很多年对于 JavaEE 项目来说再正常不过。那么我们想象一下：几百上千的人开发的项目是同一个 Web工程。那么架构师、项目经理该如何划分项目的模块、如何分工呢？这么大的项目已经不可能通过package 结构来划分模块，必须将项目拆分成多个工程协同开发。多个模块工程中有的是 Java 工程，有 的是 Web 工程。 那么工程拆分后又如何进行互相调用和访问呢？这就需要用到 Maven 的依赖管理机制。大家请看 我们的 Survey 调查项目拆分的情况：
• 2. Maven 软件的下载与安装
  • 2.1. 下载
    • http://archive.apache.org/dist/maven/maven-3/
  • 2.2. 安装
    • Maven 下载后，将 Maven 解压到一个没有中文没有空格的路径下，比如 D:\software\maven 下面
    • 目录
      • bin:存放了 maven 的命令，比如我们前面用到的 mvn tomcat:run
      • boot:存放了一些 maven 本身的引导程序，如类加载器等
      • conf:存放了 maven 的一些配置文件，如 setting.xml 文件
      • lib:存放了 maven 本身运行所需的一些 jar 包
    • Maven 及 JDK 配置
      • 电脑上需安装 java 环境，安装 JDK1.7 + 版本 （将JAVA_HOME/bin 配置环境变量 path ），
      • 配置 MAVEN_HOME ，变量值就是你的 maven 安装 的路径（bin 目录之前一级目录）
      • 上面配置了我们的 Maven 软件，注意这个目录就是之前你解压 maven 的压缩文件包在的的目录，最好不要有中文和空格。
      • JDK 的安装目录
    • Maven 软件版本测试
      • 通过 mvn -v命令检查 maven 是否安装成功，看到 maven 的版本为 3.5.2 及 java 版本为 1.8 即为安装成功。 找开 cmd 命令，输入 mvn –v命令，
    • 我们发现 maven 的版本，及 jdk 的版本符合要求，这样我们的 maven 软件安装就成功了
• 3. What?
  • 3.1. Maven 简介
    • Maven 是 Apache 软件基金会组织维护的一款自动化构建工具，专注服务于 Java 平台的项目构建和依赖管理。Maven 这个单词的本意是：专家，内行。读音是['meɪv(ə)n]或['mevn]。
  • 3.2. 定义
    • Maven 是一个项目管理工具，它包含了一个项目对象模型 (POM：Project Object Model)，一组标准集合， 一个项目生命周期(Project Lifecycle)，一个依赖管理系统(Dependency Management System)，和用来运行定义在生命周期阶段(phase)中插件(plugin)目标(goal)的逻辑。
  • 3.3. 什么是构建
    • 3.3. 构建就是以我们编写的 Java 代码、框架配置文件、国际化等其他资源文件、JSP 页面和图片等静态资源作为“原材料”，去“生产”出一个可以运行的项目的过程。
    • 构建并不是创建，创建一个工程并不等于构建一个项目。 要了解构建的含义我们应该由浅入深的从以下三个层面来看：
      • 纯 Java 代码
        • 大家都知道，我们 Java 是一门编译型语言，java 扩展名的源文件需要编译成.class 扩展名的字节码文件才能够执行。所以编写任何 Java 代码想要执行的话就必须经过编译得到对应的.class 文件。
      • Web 工程
        • 当我们需要通过浏览器访问 Java 程序时就必须将包含 Java 程序的 Web 工程编译的结果“拿”到服务器上的指定目录下，并启动服务器才行。这个“拿”的过程我们叫部署。 我们可以将未编译的 Web 工程比喻为一只生的鸡，编译好的 Web 工程是一只煮熟的鸡，编译部署的过程就是将鸡炖熟。Web 工程和其编译结果的目录结构对比见下图：
      • 实际项目
        • 在实际项目中整合第三方框架，Web 工程中除了 Java 程序和 JSP 页面、图片等静态资源之外，还包括第三方框架的 jar 包以及各种各样的配置文件。所有这些资源都必须按照正确的目录结构部署到服务器上，项目才可以运行。 所以综上所述：构建就是以我们编写的 Java 代码、框架配置文件、国际化等其他资源文件、JSP 页面和图片等静态资源作为“原材料”，去“生产”出一个可以运行的项目的过程。
  • 3.4. 构建的主要环节
    • 1. 清理：
      • 删除以前的 编译结果，为重新 编译做好准备
    • 2. 编译：
      • 将 Java 源程序编译为 字节码文件
    • 3. 测试：
      • 针对项目中的关键点进行测试，确保项目在 迭代开发过程中关键点的正确
    • 4. 报告：
      • 在每一次测试后以标准的格式记录和展示测试结果
    • 5. 打包：
      • 将一个包含诸多文件的工程封装为一个压缩文件用于安装或部署。 Java 工程 对应 jar包， Web 工程对应 war 包
    • 6. 安装：
      • 在Maven 环境下特指 将打包的结果—— jar 包 或 war 包 安装到 本地仓库中
    • 7. 部署：
      • 将打包的结果 部署到 远程仓库 或 将 war 包 部署到 服务器上运行
  • 3.5. 自动化构建
  • 3.6. Maven 核心概念
    • Maven 能够实现自动化构建是和它的内部原理分不开的，这里我们从 Maven 的九个核心概念入手，看看 Maven 是如何实现自动化构建的
      • 1. POM
        • Project Object Model：项目对象模型。将 Java 工程的相关信息封装为对象作为便于操作和管理的模型。 Maven 工程的核心配置。可以说学习 Maven 就是学习 pom.xml 文件中的配置
      • 2. 约定的目录结构
        • 约定的目录结构对于 Maven 实现自动化构建而言是必不可少的一环，就拿自动编译来说，Maven 必须能找到 Java 源文件，下一步才能编译，而编译之后也必须有一个准确的位置保持编译得到的字节码文件。 我们在开发中如果需要让第三方工具或框架知道我们自己创建的资源在哪，那么基本上就是两种方式：
          • 通过配置的形式明确告诉他
          • 基于第三方工具 或框架 的约定
      • 3. 坐标
        • 几何中的坐标
          • 在一个平面中使用 x、y 两个向量可以唯一的确定平面中的一个点。
          • 在空间中使用 x、y、z 三个向量可以唯一的确定空间中的一个点。
        • Maven 的坐标
          • 使用如下三个向量在 Maven 的仓库中唯一的确定一个 Maven 工程。
            • groupid
              • 公司 或组织的域名 倒序 + 当前项目名称
            • artifactId
              • 当前项目的模块名称
            • version
              • 当前模块的版本
        • 如何通过坐标到仓库中查找 jar 包
          • 将 gav 三个向量 连接起来
          • 以连接起来的 字符串作为目录结构 到仓库中查找
          • 注意：我们自己的 Maven 工程必须执行安装操作才会进入仓库。安装的命令是：mvn install
      • 4. 依赖管理
        • 4. Maven 中最关键的部分，我们使用 Maven 最主要的就是使用它的依赖管理功能
        • 依赖的目的是什么
          • 当 A jar 包用到了 B jar 包中的某些类时，A 就对 B 产生了依赖，这是概念上的描述。那么如何在项目中以依赖的方式引入一个我们需要的 jar 包呢？ --------------------使用 dependency 标签指定被依赖 jar 包的坐标就可以了
        • 依赖的范围
          • 大家注意到上面的依赖信息中除了目标 jar 包的坐标还有一个 scope 设置，这是依赖的范围。依赖的范 围有几个可选值，我们用得到的是：compile、test、provided 三个。
          • 从项目结构角度理解 compile 和 test 的区别
            • compile 范围依赖对主程序和测试程序都应该有效。
            • test 范围依赖仅仅对于主程序有效。
          • 从开发和运行这两个不同阶段理解 compile 和 provided 的区别
          • 有效性总结
        • 依赖的传递性
          • A 依赖 B，B 依赖 C，A 能否使用 C 呢？那要看 B 依赖 C 的范围是不是 compile，如果是则可用，否则不可用。
        • 依赖的排除
          • 如果我们在当前工程中引入了一个依赖是 A，而 A 又依赖了 B，那么 Maven 会自动将 A 依赖的 B 引入当前工程，但是个别情况下 B 有可能是一个不稳定版，或对当前工程有不良影响。这时我们可以在引入 A 的时候将 B 排除
            • 情景举例
            • 配置方式
            • 排除的效果
        • 统一管理 所依赖的jar 包 的版本
          • 对同一个框架的一组 jar 包最好使用相同的版本。为了方便升级框架，可以将 jar 包的版本信息统一提取出来
          • 统一声明版本号
            • 其中 atguigu.spring.version 部分是自定义标签。
          • 引用前面声明的版本号
          • 其它用法
        • 依赖的原则: 解决 jar 冲突
          • 路径最短者优先
          • 路径相同时 先声明者优先
      • 5. 仓库管理
        • 分类
          • 本地仓库
            • 用来存储从远程仓库或中央仓库下载的插件和 jar 包，项目使用一些插件或 jar 包，优先从本地仓库查找 默认本地仓库位置在 ${user.dir}/.m2/repository，${user.dir}表示 windows 用户目录。
            • 为当前本机电脑上的所有 Maven 工程服务
            • Maven 本地仓库的配置
              • 在 MAVE_HOME/conf/settings.xml 文件中配置本地仓库位置（maven 的安装目录下）：
              • 打开 settings.xml文件，配置如下：
              • 全局 setting 与用户 setting
                • maven 仓库地址、私服等配置信息需要在 setting.xml 文件中配置，分为全局配置和用户配置。 在 maven 安装目录下的有 conf/setting.xml 文件，此 setting.xml 文件用于 maven 的所有 project项目，它作为 maven 的全局配置。 如需要个性配置则需要在用户配置中设置，用户配置的 setting.xml 文件默认的位置在：${user.dir} /.m2/settings.xml 目录中,${user.dir} 指 windows 中的用户目录。 maven 会先找用户配置，如果找到则以用户配置文件为准，否则使用全局配置文件
          • 远程仓库
            • 如果本地需要插件或者 jar 包，本地仓库没有，默认去远程仓库下载。 远程仓库可以在互联网内也可以在局域网内。
            • 私服
              • 架设在当前局域网环境下，为当前局域网范围内的所有 Maven 服务
            • 中央仓库
              • http://repo1.maven.org/maven2
              • 架设在 Internet 上，为 全世界 所有 Maven 工程服务
            • 中央仓库的镜像
              • 架设在 各个大洲的，为 中央仓库分担流量，减轻中央仓库的压力，同时更快的响应用户请求
        • 仓库中的文件
          • Maven 插件
          • 我们自己开发的 项目的模块
          • 第三方框架的或工具 的 jar 工具
          • 不管是什么样的 jar 包 在 仓库中都是按照 坐标生成 目录结构所以可以通过统一的方式查询 或 依赖
      • 6. 生命周期
        • 什么是 Maven 的 生命周期
          • Maven 生命周期定义了各个构建环节的执行顺序，有了这个清单，Maven 就可以自动化的执行构建命 令了。
          • Maven 有三套相互独立的生命周期
            • Clean Lifecycle 在进行真正的构建之前 进行一些清理工作
            • Default Lifecycle 构建 的 核心部分 ，编译 ，测试 ， 打包，安装，部署等等
            • Site Lifecycle 生成项目报告 ，站点 ，发布站点
            • 它们是相互独立的，你可以仅仅调用 clean 来清理工作目录，仅仅调用 site 来生成站点。 当然你也可以直接运行 mvn clean install site 运行所有这三套生命周期。
        • 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 的生命周期的，因此理解生命周期至关重要。
      • 7. 插件和目标
        • ●Maven 的核心仅仅定义了抽象的生命周期，具体的任务都是交由插件完成的。
        • ●每个插件都能实现多个功能，每个功能就是一个插件目标。
        • ●Maven 的生命周期与插件目标相互绑定，以完成某个具体的构建任务。
        • 例如： compile 就是插件 maven-compiler-plugin 的一个目标； pre-clean 是插件 maven-clean-plugin 的一个目标。
      • 8. 继承
        • 为什么需要继承机制？
          • 由于非 compile 范围的依赖信息是不能在“依赖链”中传递的，所以有需要的工程只能单独配置。
            • 此时如果项目需要将各个模块的junit版本统一为4.9，那么到各个工程中手动修改无疑是非常不可取的。 使用继承机制就可以将这样的依赖信息统一提取到父工程模块中进行统一管理。
        • 创建 父工程
          • 创建父工程和创建一般的 Java 工程操作一致，唯一需要注意的是：打包方式处要设置为 pom。
        • 在子工程中引用父工程
          • 此时如果子工程的 groupId 和 version 如果和父工程重复则可以删除
        • 在父工程中管理依赖
          • 将 Parent 项目中的 dependencies 标签，用 dependencyManagement 标签括起来
          • 在子项目中重新指定需要的依赖，删除范围和版本号
      • 9. 聚合
        • 为什么要使用聚合？
          • 将多个工程拆分为模块后，需要手动逐个安装到仓库后依赖才能够生效。修改源码后也需要逐个手动进行 clean 操作。而使用了聚合之后就可以批量进行 Maven 工程的安装、清理工作。
        • 如何配置聚合？
          • 在总的聚合工程中使用 modules/module 标签组合，指定模块工程的相对路径即可
• 4. How？
  • 4.1. Maven 的核心程序中仅仅定义了抽象的生命周期，而具体的操作则是由 Maven 的插件来完成的。可是Maven 的插件并不包含在 Maven 的核心程序中，在首次使用时需要联网下载。
  • 4.2. 下载得到的插件会被保存到本地仓库中。本地仓库默认的位置是：~\.m2\repository。
  • 4.3. Maven 工程的认识
    • 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 工程的运行
      • 进入 maven 工程目录（当前目录有 pom.xml 文件），运行 tomcat:run 命令。
      • 根据上边的提示信息，通过浏览器访问：http://localhost:8080/maven-helloworld/
    • 问题处理
      • 如果本地仓库配置错误会报下边的错误
      • 分析：
        • maven 工程运行先从本地仓库找 jar 包，本地仓库没有再从中央仓库找，上边提示 downloading… 表示 从中央仓库下载 jar，由于本地没有联网，报错
      • 解决：
        • 在 maven 安装目录的 conf/setting.xml 文件中配置本地仓库，
  • 4.4. Maven 常用命令
    • 4.4. 我们可以在 cmd 中通过一系列的 maven 命令来对我们的 maven-helloworld 工程进行编译、测试、运行、打包、安装、部署
    • complie
      • compile 是 maven 工程的编译命令，作用是将 src/main/java 下的文件编译为 class 文件输出到 target目录下。
      • cmd 进入命令状态，执行 mvn compile，如下图提示成功：
      • 查看 target 目录，class 文件已生成，编译完成。
    • test
      • test 是 maven 工程的测试命令 mvn test，会执行 src/test/java 下的单元测试类。
      • cmd 执行 mvn test 执行 src/test/java 下单元测试类，下图为测试结果，运行 1 个测试用例，全部成功。
    • clean
      • clean 是 maven 工程的清理命令，执行 clean 会删除 target 目录及内容
    • package
      • package 是 maven 工程的打包命令，对于 java 工程执行 package 打成 jar 包，对于 web 工程打成 war包。
    • install
      • install 是 maven 工程的安装命令，执行 install 将 maven 打成 jar 包或 war 包发布到本地仓库。
      • 从运行结果中，可以看出： 当后面的命令执行时，前面的操作过程也都会自动执行，
    • maven 的概念模型
      • Maven 包含了一个项目对象模型 (Project Object Model)，一组标准集合，一个项目生命周期(Project Lifecycle)，一个依赖管理系统(Dependency Management System)，和用来运行定义在生命周期阶段(phase)中插件(plugin)目标(goal)的逻辑。
      • 项目对象模型 (Project Object Model)
        • 一个 maven 工程都有一个 pom.xml 文件，通过 pom.xml 文件定义项目的坐标、项目依赖、项目信息、插件目标等。
      • 依赖管理系统(Dependency Management System)
        • 通过 maven 的依赖管理对项目所依赖的 jar 包进行统一管理。
          • 比如：项目依赖 junit4.9，通过在 pom.xml 中定义 junit4.9 的依赖即使用 junit4.9，如下所示是 junit4.9的依赖定义：
      • 一个项目生命周期(Project Lifecycle)
        • 使用 maven 完成项目的构建，项目构建包括：清理、编译、测试、部署等过程，maven 将这些过程规范为一个生命周期，如下所示是生命周期的各各阶段：
        • maven 通过执行一些简单命令即可实现上边生命周期的各各过程， 比如执行 mvn compile 执行编译、执行 mvn clean 执行清理
      • 一组标准集合
        • maven 将整个项目管理过程定义一组标准， 比如：通过 maven 构建工程有标准的目录结构，有标准的生命周期阶段、依赖管理有标准的坐标定义等
      • 插件(plugin)目标(goal)
        • maven 管理项目生命周期过程都是基于插件完成的。
    • idea 开发 maven 项目
      • idea 的 maven 配置
        • 打开FileSettings 配置 maven
        • 依据图片指示，选择本地 maven 安装目录，指定 maven 安装目录下 conf 文件夹中 settings 配置文件。
      • idea 中创建一个 maven 的 web 工程
        • 选择 idea 提供好的 maven 的web 工程模板
        • 点击 Next 填写项目信息
        • 点击 Next，此处不做改动。
        • 点击 Next 选择项目所在目录
        • 点击 Finish 后开始创建工程，耐心等待，直到出现如下界面。
        • 手动添加 src/main/java 目录，如下图右键 main 文件夹NewDirectory
        • 创建一个新的文件夹命名为 java
        • 点击 OK 后，在新的文件夹 java 上右键Make Directory asSources Root
        • 创建一个 Servlet src/java/main 创建了一个 Servlet，但报错: 要解决问题，就是要将 servlet-api-xxx.jar 包放进来，作为 maven 工程应当添加 servlet 的坐标，从而导入它的 jar
        • 在 pom.xml 文件添加坐标 直接打开 hello_maven 工程的 pom.xml 文件，再添加坐标
        • 添加 jar 包的坐标时，还可以指定这个 jar 包将来的作用范围。 每个 maven 工程都需要定义本工程的坐标，坐标是 maven 对 jar 包的身份定义，比如：入门程序的坐标定义如下
        • 坐标的来源方式
          • 添加依赖需要指定依赖 jar 包的坐标，但是很多情况我们是不知道 jar 包的的坐标，可以通过如下方 式查询：
            • 从互联网搜索
              • http://search.maven.org/
              • http://mvnrepository.com/
        • 依赖范围
          • 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
        • 项目中添加的坐标
        • 设置 jdk 编译版本 使用 maven 的插件来设置： 在 pom.xml 中加入：
        • 编写 servlet 在 src/main/java 中创建 ServletTest
        • 编写 jsp
        • 在 web.xml 中配置 servlet 访问路径
        • 添加 tomcat7 插件 在 pom 文件中添加如下内容
        • 此时点击 idea 最右侧 Maven Projects， 就可以看到我们新添加的 tomcat7 插件 双击 tomcat7插件下 tomcat7:run 命令直接运行项目
          • 也可以直接点击如图按钮，手动输入 tomc7:run 命令运行项目
        • 运行结果
    • Eclipse 开发 maven 项目
      • 在Eclipse中设置Maven插件
      • 创建Java工程
      • 创建Web工程
  • 4.5. maven 工程运行调试
    • 端口占用处理
      • 重新执行 tomcat:run 命令重启工程，重启之前需手动停止 tomcat，否则报下边的错误：
    • 断点调试
      • 点击如图所示选项
      • 在弹出框中点击如图加号按钮找到 maven 选项
      • 在弹出窗口中填写如下信息
      • 完成后先 Apply 再 OK 结束配置后，可以在主界面找到我们刚才配置的操作名称
  • 4.6. pom 基本配置
    • <project > ：文件的根节点 .
    • <modelversion > ： pom.xml 使用的对象模型版本
    • <groupId > ：项目名称，一般写项目的域名
    • <artifactId > ：模块名称，子项目名或模块名称
    • <version > ：产品的版本号 .
    • <packaging > ：打包类型，一般有 jar、war、pom 等
    • <name > ：项目的显示名，常用于 Maven 生成的文档。
    • <description > ：项目描述，常用于 Maven 生成的文档
    • <dependencies> ：项目依赖构件配置，配置项目依赖构件的坐标
    • <build> ：项目构建配置，配置编译、运行插件等。
    • pom.xml 是 Maven 项目的核心配置文件，位于每个工程的根目录
• 5. Maven 酷站
  • 5. 我们可以到 http://mvnrepository.com/搜索需要的 jar 包的依赖信息。
  • 5.1. http://mvnrepository.com/
• 导言：生产环境下开发不再是一个项目一个工程，而是每一个模块创建一个工程，而多个模块整合在一起就需要 使用到像 Maven 这样的构建工具。