Maven的使用

Maven

目前项目状况
①添加第三方 jar 包

使用这些 jar 包最简单的方法就是复制粘贴到 WEB-INF/lib 目录下。但是这会导致每次创建一个新的工程就需要将 jar
包重复复制到 lib 目录下，从而造成工作区中存在大量重复的文件，让我们的工程显得很臃肿。 而使用 Maven 后每个 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 包

jar 包种类繁多，几乎每个 jar 包在其本身的官网上的获取方式都不尽相同。使用 Maven 我们可以享受到一个完全统一规范的 jar
包管理体系。你只需要在你的项目中以坐标的方式依赖一个 jar 包，Maven 就会自动从中央仓库进行下载，并同时下载这个 jar
包所依赖的其他 jar 包

④将项目拆分成多个工程模块

随着 JavaEE 项目的规模越来越庞大，开发团队的规模也与日俱增。一个项目上千人的团队持续开发很多年对于 JavaEE
项目来说再正常不过。那么我们想象一下：几百上千的人开发的项目是同一个 Web
工程。那么架构师、项目经理该如何划分项目的模块、如何分工呢？这么大的项目已经不可能通过 package
结构来划分模块，必须将项目拆分成多个工程协同开发。多个模块工程中有的是 Java 工程，有的是 Web 工程。
那么工程拆分后又如何进行互相调用和访问呢？这就需要用到 Maven 的依赖管理机制。

Maven简介

Maven 是 Apache 软件基金会组织维护的一款自动化构建工具，专注服务于 Java 平台的项目构建和依赖管理。Maven 这个单词的本意是：专家，内行。读音是['meɪv(ə)n]或['mevn]。
Make->ant->Maven->Gradle
构建并不是创建，创建一个工程并不等于构建一个项目。要了解构建的含义我们应该由浅入深的从以下三个层面来看：

①纯 Java 代码 大家都知道，我们 Java 是一门编译型语言，.java 扩展名的源文件需要编译成.class
扩展名的字节码文件才能够执行。 ②Web 工程 当我们需要通过浏览器访问 Java 程序时就必须将包含 Java 程序的 Web
工程编译的结果“拿”到服务器上的指定目录下，并启动服务器才行。这个过程我们叫部署。 ③实际项目 在实际项目中整合第三方框架，Web
工程中除了 Java 程序和 JSP 页面、图片等静态资源之外，还包括第三方框架的 jar
包以及各种各样的配置文件。所有这些资源都必须按照正确的目录结构部署到服务器上，项目才可以运行。

所以综上所述：构建就是以我们编写的 Java 代码、框架配置文件、国际化等其他资源文件、JSP 页面和图片等静态资源作为“原材料”，去“生产”出一个可以运行的项目的过程。
那么项目构建的全过程中都包含哪些环节呢？
构建过程的几个主要环节

①清理：删除以前的编译结果（class文件），为重新编译做好准备。
②编译：将 Java 源程序编译为字节码文件。
③测试：（自动测试）针对项目中的关键点进行测试，确保项目在迭代开发过程中关键点的正确性。
④报告：在每一次测试后以标准的格式记录和展示测试结果。
⑤打包：将一个包含诸多文件的工程封装为一个压缩文件用于安装或部署。Java 工程对应 jar 包，Web工程对应 war 包。
⑥安装：在 Maven 环境下特指将打包的结果——jar 包或 war 包安装到本地仓库中。
⑦部署：将打包的结果部署到远程仓库或将 war 包部署到服务器上运行。

运行时环境：（查看build->）

安装Maven

1.解压部署Maven核心程序
	①检查JAVA_HOME环境变量
		C:\Windows\System32>echo %JAVA_HOME%
		d:\software\jdk1.7.0_07
	②解压Maven的核心程序
		将apache-maven-3.2.2-bin.zip解压到一个非中文无空格的目录下。例如：d:\software\apache-maven-3.2.2
	③配置环境变量
		path	d:\software\apache-maven-3.2.2\bin
	④查看Maven版本信息验证安装是否正确
		C:\Windows\System32>mvn -v
		Apache Maven 3.2.2 (45f7c06d68e745d05611f7fd14efb6594181933e; 2014-06-17T21:51:42+08:00)
		Maven home: d:\software\apache-maven-3.2.2\bin\..
		Java version: 1.7.0_07, vendor: Oracle Corporation
		Java home: d:\software\jdk1.7.0_07\jre
		Default locale: zh_CN, platform encoding: GBK
		OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows"

Maven核心概念

Maven 能够实现自动化构建是和它的内部原理分不开的，这里我们从 Maven 的九个核心概念入手，

①POM
②约定的目录结构
③坐标
④依赖管理
⑤仓库管理
⑥生命周期
⑦插件和目标
⑧继承
⑨聚合

Maven安装目录及配置文件
1、修改本地仓库

①默认本地仓库位置：~\.m2\repository
		~表示当前用户的家目录，
		例如：C:\Users\[你当前登录系统的用户名]
	②指定本地仓库位置的配置信息文件：
		apache-maven-3.2.2\conf\settings.xml
	③在根标签settings下添加如下内容：
		[本地仓库路径，也就是RepMaven.zip的
		解压目录]
	※注意：运行Maven命令时一定要进入pom.xml文件所在的目录！
几个基本的Maven命令
		mvn compile	编译主程序
		mvn test-compile	编译测试程序
		mvn clean	清理
		mvn test	测试
		mvn package	打包

①清理：删除以前的编译结果，为重新编译做好准备。
②编译：将 Java 源程序编译为字节码文件。

③测试：针对项目中的关键点进行测试，确保项目在迭代开发过程
中关键点的正确性。
④报告：在每一次测试后以标准的格式记录和展示测试结果。
⑤打包：将一个包含诸多文件的工程封装为一个压缩文件用于安装或部署。
Java 工程对应 jar 包，Web工程对应 war 包。
⑥安装：在 Maven 环境下特指将打包的结果——jar 包或 war 包
安装到本地仓库中。
⑦部署：将打包的结果部署到远程仓库或将 war 包部署到服务器上运行。

第一个Maven程序

POM

Project Object Model：项目对象模型。将 Java 工程的相关信息封装为对象作为便于操作和管理的模型。 pom.xml 是Maven 工程的核心配置

坐标
1、几何中的坐标

[1]在一个平面中使用 x、y 两个向量可以唯一的确定平面中的一个点。

[2]在空间中使用 x、y、z 三个向量可以唯一的确定空间中的一个点。

2、Maven 的坐标
使用如下三个向量在 Maven 的仓库中唯一的确定一个 Maven 工程。

[1]groupid：公司或组织的域名倒序+当前项目名称

[2]artifactId：当前项目的模块名称

[3]version：当前模块的版本

com.hqyj.maven 
Hello
0.0.1-SNAPSHOT

3、如何通过坐标到仓库中查找 jar 包？

[1]将 gav 三个向量连起来 com. hqyj.maven+Hello+0.0.1-SNAPSHOT

[2]以连起来的字符串作为目录结构到仓库中查找 com/ hqyj /maven/Hello/0.0.1-SNAPSHOT/Hello-0.0.1-SNAPSHOT.jar

※注意：我们自己的 Maven 工程必须执行安装操作才会进入仓库。安装的命令是：mvn install

仓库

分类 本地仓库：为当前本机电脑上的所有 Maven 工程服务。 远程仓库 局域网（私服）：架设在当前局域网环境下，为当前局域网范围内的所有
Maven 工程服务。

中央仓库：架设在 Internet 上，为全世界所有 Maven 工程服务。
中央仓库镜像：架设在各个大洲，为中央仓库分担流量。减轻中央仓库的压力，同时更快的
存放内容（Maven项目）
所需插件
第三方框架或工具使用jar包
自己开发的maven项目

依赖

setting.xml中的配置

修改jdk

	    
    jdk-1.8    
         
          true    
          1.8    
          
	    
		1.8    
		1.8    
		1.8    
	    
	

修改本地仓库路径
D:\Maven Repository

Maven 中最关键的部分，我们使用 Maven 最主要的就是使用它的依赖管理功能。要理解和掌握 Maven 的依赖管理，我们只需要解决一下几个问题：

1、依赖的目的是什么
当 A jar 包用到了 B jar 包中的某些类时，A 就对 B 产生了依赖，这是概念上的描述。那么如何在项目中以依赖的方式引入一个我们需要的 jar 包呢？
答案非常简单，就是使用 dependency 标签指定被依赖 jar 包的坐标就可以了。

com.hqyj.maven
Hello
0.0.1-SNAPSHOT
compile

2、依赖的范围
大家注意到上面的依赖信息中除了目标 jar 包的坐标还有一个 scope 设置，这是依赖的范围。依赖的范围有几个可选值，我们用得到的是：compile、test、provided 三个。
既标签的可选配置：compile、test、provided、runtime、system、import，下面一一介绍
1)编译依赖范围（compile），该范围就是默认依赖范围，此依赖范围对 于编译、测试、运行三种classpath都有效，举个简单的例子，假如项目中有spring-core的依赖，那么spring-core不管是在编译，测试，还是运行都会被用到，因此spring-core必须是编译范围（构件默认的是编译范围，所以依赖范围是编译范围的无须显示指定）

 
  org.springframework
  spring-core
  2.5
  compile 
        
            
                zzq.mavenProject
                project01
            
        
    

这样在project03中就不会依赖进来project01
统一版本
统一管理依赖的版本:

这里对Spring各个jar包的依赖版本都是4.0.0
如果需要统一升级为4.1.1,怎么办?手动在pom.xml中逐一修改是不可靠的!!!
可靠的配置方式:
使用标签内使用 自定义标签 统一声明版本号

    1.可靠的配置方式

        4.1.1.RELEASE

---

 2. 在需要统一版本的位置,使用`${自定义标签名}`引用声明的版本号

    
        org.springframework
        spring-context
        ${hqyj.spring.version}
    
    
        org.springframework
        spring-jdbc
        ${hqyj.spring.version}
    
    
        org.springframework
        spring-orm
        ${hqyj.spring.version}
    
    
        org.springframework
        spring-web
        ${hqyj.spring.version}
    

其实标签配合自定义标签声明数据的配置并不是只能用于声明依赖的版本号,凡是需要统一声明后再引用的场合都可以使用,例如:统一配置项目构建的源码的字符集格式

        UTF-8

继承

现状：
project1:junit包：4.0
project2:junit包：4.0
project3:junit包：4.1
需求，需要将三个包版本统一
为了减少重复代码的编写，我们需要创建POM的父子结构，然后在POM中申明一些配置供子POM继承，以实现“一处申明，多处使用的”目的。以之前的模块中的结构为基础，在account-aggregator下创建一个account-parent的子目录，然后在该子目录下创建除account-aggregator模块之外的模块的父模块。为此在该子目录下创建一个pom.xml文件如下：

  
  
4.0.0  
        com.juvenxu.mvnbook.account  
        account-parent  
        1.0.0-SNAPSHOT  
        pom   
 

需要注意的是它的packaging的值必须为pom，这一点与模块聚合一样，作为负模块的POM，其打包类型也必须为pom。由于父模块只是为了消除配置的重复，因此也就不需要src/main/java等目录了。

有了父模块就让其他子模块来继承它，修改account-email的pom文件如下：

  
  
4.0.0 
        
            com.juvenxu.mvnbook.account  
            account-parent  
            1.0.0-SNAPSHOT  
            ../account-parent/pom.xml  
         
       

parent下的子元素groupId、artifactId和version指定了父模块的坐标，这三个元素是必须的。元素relativePath表示父模块POM的相对路径。当项目构建时，Maven会首先根据relativePath检查父POM，如果找不到，再从本地仓库查找。relativePath的默认值是…/pom.xml，也就是说，Maven默认父POM在上一层目录下。
注：父项目一定要是pom类型，其次…/account-parent/pom.xml

聚合

  
    ../task-common  
    ../task-sla  
    ../task-sla-web  
    ../task-web-dist