Maven 简洁

Maven 简要

1.前言

Maven，发音是[`meivin]，"专家"的意思。它是一个很好的项目管理工具，很早就进入了我的必备工具行列，但是这次为了把project1项目完全迁移并应用maven，所以对maven进行了一些深入的学习。写这个学习笔记的目的，一个是为了自己备忘，二则希望能够为其他人学习使用maven 缩短一些时间。

2. maven概要

首先我把maven的概念快速的梳理一下，让我们快速地建立起一个比较精确的maven应用场景。

2.1 maven不是什么

读书时候要先限定范围，避免一些有害的遐想。要说maven不是什么，我们可以从如下几个要点来展开

1. maven不是ant，也不是make。?
   我们以前接触的构建工具，需要写一些详细的步骤，比如：?compile project1/src/*.java?等类似的语句。这些语句正是我们使用ant和make所要编写的东西。maven采用了"约定优于配置"的方法，一些开发常用的操作和步骤已经固化在 maven中，所以使用者不再需要去编写那些烦人的语句了。同时，maven内置了开发流程的支持，它不仅能够编译，同样能够打包、发布，也能够一气呵成做完这些所有的步骤。
2. maven不是ivy?
   依赖管理是maven的功能之一，虽然很多人包括我以前都是只用它的依赖管理功能，但是要深入运用的话，我们就可以看到更多的内容。更重要的是，maven在依赖关系中加入了scope的概念，进一步细化了依赖关系的划分。

2.2 maven是什么

maven将自己定位为一个项目管理工具。它负责管理项目开发过程中的几乎所有的东西：

1. 版本?
   maven有自己的版本定义和规则
2. 构建?
   maven支持许多种的应用程序类型，对于每一种支持的应用程序类型都定义好了一组构建规则和工具集。
3. 输出物管理?
   maven可以管理项目构建的产物，并将其加入到用户库中。这个功能可以用于项目组和其他部门之间的交付行为。
4. 依赖关系?
   maven对依赖关系的特性进行细致的分析和划分，避免开发过程中的依赖混乱和相互污染行为
5. 文档和构建结果?
   maven的site命令支持各种文档信息的发布，包括构建过程的各种输出，javadoc，产品文档等。
6. 项目关系?
   一个大型的项目通常有几个小项目或者模块组成，用maven可以很方便地管理
7. 移植性管理?
   maven可以针对不同的开发场景，输出不同种类的输出结果。

2.3 maven的生命周期

maven把项目的构建划分为不同的生命周期(lifecycle)，在我看来，划分的已经是非常仔细了，大家可以参考这里?。粗略一点的话，它这个过程(phase)包括：编译、测试、打包、集成测试、验证、部署。maven中所有的执行动作(goal)都需要指明自己在这个过程中的执行位置，然后maven执行的时候，就依照过程的发展依次调用这些goal进行各种处理。

这个也是maven的一个基本调度机制。一般来说，位置稍后的过程都会依赖于之前的过程。当然，maven同样提供了配置文件，可以依照用户要求，跳过某些阶段。

2.4 maven的"约定优于配置"

所谓的"约定优于配置"，在maven中并不是完全不可以修改的，他们只是一些配置的默认值而已。但是使用者除非必要，并不需要去修改那些约定内容。maven默认的文件存放结构如下：

• /项目目录
  • pom.xml 用于maven的配置文件
  • /src 源代码目录
    • /src/main 工程源代码目录
      • /src/main/java 工程java源代码目录
      • /src/main/resource 工程的资源目录
      • /src/test 单元测试目录
        • /src/test/java
        • /target 输出目录，所有的输出物都存放在这个目录下
          • /target/classes 编译之后的class文件

            每一个阶段的任务都知道怎么正确完成自己的工作，比如compile任务就知道从src/main/java下编译所有的java文件，并把它的输出class文件存放到target/classes中。

            对maven来说，采用"约定优于配置"的策略可以减少修改配置的工作量，也可以降低学习成本，更重要的是，给项目引入了统一的规范。

            2.5 maven的版本规范

            maven使用如下几个要素来唯一定位某一个输出物：?groupId:artifactId:packaging:version?。比如?org.springframework:spring:2.5?。每个部分的解释如下：

            • groupId?
              团体，公司，小组，组织，项目，或者其它团体。团体标识的约定是，它以创建这个项目的组织名称的逆向域名(reverse domain name)开头。来自Sonatype的项目有一个以com.sonatype开头的groupId，而Apache Software的项目有以org.apache开头的groupId。
            • artifactId?
              在groupId下的表示一个单独项目的唯一标识符。比如我们的tomcat, commons等。不要在artifactId中包含点号(.)。
            • version?
              一个项目的特定版本。发布的项目有一个固定的版本标识来指向该项目的某一个特定的版本。而正在开发中的项目可以用一个特殊的标识，这种标识给版本加上一个"SNAPSHOT"的标记。?
              虽然项目的打包格式也是Maven坐标的重要组成部分，但是它不是项目唯一标识符的一个部分。一个项目的 groupId:artifactId:version使之成为一个独一无二的项目；你不能同时有一个拥有同样的groupId, artifactId和version标识的项目。
            • packaging?
              项目的类型，默认是jar，描述了项目打包后的输出。类型为jar的项目产生一个JAR文件，类型为war的项目产生一个web应用。
            • classifier?
              很少使用的坐标，一般都可以忽略classifiers。如果你要发布同样的代码，但是由于技术原因需要生成两个单独的构件，你就要使用一个分类器（classifier）。例如，如果你想要构建两个单独的构件成JAR，一个使用Java 1.4编译器，另一个使用Java 6编译器，你就可以使用分类器来生成两个单独的JAR构件，它们有同样的groupId:artifactId:version组合。如果你的项目使用本地扩展类库，你可以使用分类器为每一个目标平台生成一个构件。分类器常用于打包构件的源码，JavaDoc或者二进制集合。

              maven有自己的版本规范，一般是如下定义?<major version>.<minor version>.<incremental version>-<qualifier>?，比如1.2.3-beta-01。要说明的是，maven自己判断版本的算法是major,minor,incremental部分用数字比较，qualifier部分用字符串比较，所以要小心 alpha-2和alpha-15的比较关系，最好用 alpha-02的格式。

              maven在版本管理时候可以使用几个特殊的字符串?SNAPSHOT?,LATEST?,RELEASE?。比如"1.0-SNAPSHOT"。各个部分的含义和处理逻辑如下说明：

              • SNAPSHOT?
                如果一个版本包含字符串"SNAPSHOT"，Maven就会在安装或发布这个组件的时候将该符号展开为一个日期和时间值，转换为UTC时间。例如，"1.0-SNAPSHOT"会在2010年5月5日下午2点10分发布时候变成1.0-20100505-141000-1。?
                这个词只能用于开发过程中，因为一般来说，项目组都会频繁发布一些版本，最后实际发布的时候，会在这些snapshot版本中寻找一个稳定的，用于正式发布，比如1.4版本发布之前，就会有一系列的1.4-SNAPSHOT，而实际发布的1.4，也是从中拿出来的一个稳定版。
              • LATEST?
                指某个特定构件的最新发布，这个发布可能是一个发布版，也可能是一个snapshot版，具体看哪个时间最后。
              • RELEASE?
                指最后一个发布版。

                2.6 maven的组成部分

                maven把整个maven管理的项目分为几个部分，一个部分是源代码，包括源代码本身、相关的各种资源，一个部分则是单元测试用例，另外一部分则是各种maven的插件。对于这几个部分，maven可以独立管理他们，包括各种外部依赖关系。

                2.7 maven的依赖管理

                依赖管理一般是最吸引人使用maven的功能特性了，这个特性让开发者只需要关注代码的直接依赖，比如我们用了spring，就加入spring依赖说明就可以了，至于spring自己还依赖哪些外部的东西，maven帮我们搞定。

                任意一个外部依赖说明包含如下几个要素：groupId, artifactId, version, scope, type, optional。其中前3个是必须的，各自含义如下：

                • groupId 必须
                • artifactId 必须
                • version 必须。?
                  这里的version可以用区间表达式来表示，比如(2.0,)表示>2.0，[2.0,3.0)表示2.0<=ver<3.0；多个条件之间用逗号分隔，比如[1,3),[5,7]。
                • scope 作用域限制
                • type 一般在pom引用依赖时候出现，其他时候不用
                • optional 是否可选依赖

                  maven认为，程序对外部的依赖会随着程序的所处阶段和应用场景而变化，所以maven中的依赖关系有作用域(scope)的限制。在maven中，scope包含如下的取值：

                  • compile（编译范围）?
                    compile是默认的范围；如果没有提供一个范围，那该依赖的范围就是编译范围。编译范围依赖在所有的classpath中可用，同时它们也会被打包。
                  • provided（已提供范围）?
                    provided依赖只有在当JDK或者一个容器已提供该依赖之后才使用。例如，如果你开发了一个web应用，你可能在编译classpath中需要可用的Servlet API来编译一个servlet，但是你不会想要在打包好的WAR中包含这个Servlet API；这个Servlet API JAR由你的应用服务器或者servlet容器提供。已提供范围的依赖在编译classpath（不是运行时）可用。它们不是传递性的，也不会被打包。
                  • runtime（运行时范围）?
                    runtime依赖在运行和测试系统的时候需要，但在编译的时候不需要。比如，你可能在编译的时候只需要JDBC API JAR，而只有在运行的时候才需要JDBC驱动实现。
                  • test（测试范围）?
                    test范围依赖 在一般的 编译和运行时都不需要，它们只有在测试编译和测试运行阶段可用。测试范围依赖在之前的???中介绍过。
                  • system（系统范围）?
                    system范围依赖与provided类似，但是你必须显式的提供一个对于本地系统中JAR文件的路径。这么做是为了允许基于本地对象编译，而这些对象是系统类库的一部分。这样的构件应该是一直可用的，Maven也不会在仓库中去寻找它。?如果你将一个依赖范围设置成系统范围，你必须同时提供一个systemPath元素?。注意该范围是不推荐使用的（你应该一直尽量去从公共或定制的Maven仓库中引用依赖）。

                    另外，代码有代码自己的依赖，各个maven使用的插件也可以有自己的依赖关系。依赖也可以是可选的，比如我们代码中没有任何cache依赖，但是hibernate可能要配置cache，所以该cache的依赖就是可选的。

                    2.8 多项目管理

                    maven的多项目管理也是非常强大的。一般来说，maven要求同一个工程的所有子项目都放置到同一个目录下，每一个子目录代表一个项目，比如

                    • 总项目/
                      • pom.xml 总项目的pom配置文件
                      • 子项目1/
                        • pom.xml 子项目1的pom文件
                        • 子项目2/
                          • pom.xml 子项目2的pom文件

                            按照这种格式存放，就是继承方式，所有具体子项目的pom.xml都会继承总项目pom的内容，取值为子项目pom内容优先。

                            要设置继承方式，首先要在总项目的pom中加入如下配置

                            ${pom.project.build.directory?}
                          • ${project.build.?outputD?irectory?}?results in the path to your "target/classes" dir
                          • ${project.name?} refers to the name of the project.
                          • ${project.version?} refers to the version of the project.
                          • ${project.build.finalName?} refers to the final name of the file created when the built project is packaged
                          • 本地用户设定?
                            所有用的的 settings.xml 中的设定都可以通过?settings.?前缀进行引用
                            • ${settings.localRepository?} refers to the path of the user's local repository.
                            • ${maven.repo.local?} also works for backward compatibility with maven1 ??
                            • 环境变量?
                              系统的环境变量通过?env.?前缀引用
                              • ${env.M2_HOME?} returns the Maven2 installation path.
                              • ${java.home?} specifies the path to the current JRE_HOME environment use with relative paths to get for example:?
                                <jvm>${java.home}../bin/java.exe</jvm>
                              • java系统属性?
                                所有JVM中定义的java系统属性.
                              • 用户在pom中定义的自定义属性复制代码则引用 ${my.filter.value?} 就会得到值?hello?
                              • 上级工程的变量?
                                上级工程的pom中的变量用前缀?${project.parent?} 引用. 上级工程的版本也可以这样引用:?${parent.version?}.

                                3.6 maven的使用

                                我们已经知道maven预定义了许多的阶段（phase），每个插件都依附于这些阶段，并且在进入某个阶段的时候，调用运行这些相关插件的功能。我们先来看完整的maven生命周期：

                                生命周期阶段描述validate验证项目是否正确，以及所有为了完整构建必要的信息是否可用generate-sources生成所有需要包含在编译过程中的源代码process-sources处理源代码，比如过滤一些值generate-resources生成所有需要包含在打包过程中的资源文件process-resources复制并处理资源文件至目标目录，准备打包compile编译项目的源代码process-classes后处理编译生成的文件，例如对Java类进行字节码增强（bytecode enhancement）generate-test-sources生成所有包含在测试编译过程中的测试源码process-test-sources处理测试源码，比如过滤一些值generate-test-resources生成测试需要的资源文件process-test-resources复制并处理测试资源文件至测试目标目录test-compile编译测试源码至测试目标目录test使用合适的单元测试框架运行测试。这些测试应该不需要代码被打包或发布prepare-package在真正的打包之前，执行一些准备打包必要的操作。这通常会产生一个包的展开的处理过的版本（将会在Maven 2.1+中实现）package将编译好的代码打包成可分发的格式，如JAR，WAR，或者EARpre-integration-test执行一些在集成测试运行之前需要的动作。如建立集成测试需要的环境integration-test如果有必要的话，处理包并发布至集成测试可以运行的环境post-integration-test执行一些在集成测试运行之后需要的动作。如清理集成测试环境。verify执行所有检查，验证包是有效的，符合质量规范install安装包至本地仓库，以备本地的其它项目作为依赖使用deploy复制最终的包至远程仓库，共享给其它开发人员和项目（通常和一次正式的发布相关）

                                maven核心的插件列表可以参考?http://maven.apache.org/plugins/index.html?。这里仅列举几个常用的插件及其配置参数：

                                1. clean插件?
                                   只包含一个goal叫做?clean:clean?，负责清理构建时候创建的文件。 默认清理的位置是如下几个变量指定的路径?project.build.directory, project.build.outputDirectory, project.build.testOutputDirectory, and project.reporting.outputDirectory?。
                                2. compiler插件?
                                   包含2个goal，分别是?compiler:compile?和?compiler:testCompile?。可以到这里查看两者的具体参数设置：compile?,?testCompile?。
                                3. surefire插件?
                                   运行单元测试用例的插件，并且能够生成报表。包含一个goal为?surefire:test?。主要参数testSourceDirectory用来指定测试用例目录，参考完整用法帮助
                                4. jar?
                                   负责将工程输出打包到jar文件中。包含两个goal，分别是?jar:jar?,?jar:test-jar?。两个goal负责从classesDirectory或testClassesDirectory中获取所有资源，然后输出jar文件到outputDirectory中。
                                5. war?
                                   负责打包成war文件。常用goal有?war:war?，负责从warSourceDirectory（默认${basedir}/src/main/webapp）打包所有资源到outputDirectory中。
                                6. resources?
                                   负责复制各种资源文件，常用goal有?resources:resources?，负责将资源文件复制到outputDirectory中，默认为${project.build.outputDirectory}。
                                7. install?
                                   负责将项目输出(install:install)或者某个指定的文件(install:install-file)加入到本机库%USERPROFILE%/.m2/repository中。可以用?install:help?寻求帮助。
                                8. deploy?
                                   负责将项目输出(deploy:deploy)或者某个指定的文件(deploy:deploy-file)加入到公司库中。
                                9. site?
                                   将工程所有文档生成网站，生成的网站界面默认和apache的项目站点类似，但是其文档用doxia格式写的，目前不支持docbook，需要用其他插件配合才能支持。需要指出的是，在maven 2.x系列中和maven3.x的site命令处理是不同的，在旧版本中，用 mvn site 命令可以生成reporting节点中的所有报表，但是在maven3中，reporting过时了，要把这些内容作为 maven-site-plugin的configuration的内容才行。详细内容可以参考http://www.wakaleo.com/blog/292-site-generation-in-maven-3?