Maven知识整理

1、概念：

Maven是一个项目管理工具，它包含了一个项目对象模型(Project Object Model)，一组标准集合，一个项目生命周期(Project Lifecycle)，一个依赖管理系统(Dependency Management System)，和用来运行定义在生命周期阶段(phase)中插件(plugin)目标(goal)的逻辑。

一、项目构建流程：

 

二、Maven项目目录：

 

2、仓库：

Maven的仓库三种：本地仓库、中央仓库、远程仓库；

(一) 本地仓库：

本地仓库是指 maven 下载了插件或者 jar 文件后存放在本地机器上的拷贝。在 Linux 上，它的位置在 ~/.m2/repository，在 Windows XP 上，在 C:\Documents and Settings\username\.m2\repository ，在 Windows 7 上，在 C:\Users\username\.m2\repository。当 maven 查找须要的 jar 文件时，它会先在本地仓库中寻找，只有在找不到的状况下，才会去远程库中找。

能够在%MAVEN_HOME%/conf/settings.xml中设置localRepository的值来修改本地仓库路径

运行 mvn install 能够把咱们的项目安装到本地库；

(二) 中央仓库：

Maven的中央仓库由Maven社区提供，默认地址是http://repo1.maven.org/maven2，全部不在本地仓库中的依赖都会去这个中央仓库查找。而后Maven会将这些依赖下载到你的本地仓库。访问中央仓库不须要作额外的配置。

(三) 远程仓库：

远程仓库通常用于放置组织内部的项目，该项目由多个项目共享；

远程仓库是位于web服务器上的一个仓库，Maven能够从该仓库下载依赖，就像从中央仓库下载依赖同样。远程仓库能够位于Internet上的任何地方，也能够是位于本地网络中。

远程仓库不能被外部访问，所以不能放在公开的中央仓库下，而应该放到内部的远程仓库中。

远程仓库中的依赖也会被Maven下载到本地仓库中。

能够在pom文件里配置远程仓库。将如下的xml片断放到属性以后：

1 <repositories> 2 　　<repository> 3 　　　　<id>jenkov.code</id> 4 　　　　<url>http://maven.jenkov.com/maven2/lib</url> 5 　　</repository> 6 </repositories>

3、安装：

一、JDK的安装；

二、在Apache的官网上http://maven.apache.org/download.cgi下载最新版本的Binary zip archive包并解压到硬盘上的某个路径下；

三、配置环境变量：

a) 添加环境变量M2_HOME，值为maven包的路径；

b) 在环境变量PATH里面添加maven的bin的路径；

四、测试安装是否成功：

在cmd命令行窗口下输入：mvn –version，若是显示出maven的版本号，则说明安装成功；

五、Eclipse配置：

a) 配置maven的安装路径：

 

在上图中点击“Add”按钮，而后Maven的路径，肯定后就会在列表中显示；

b) 配置maven 本地库的路径：

 

在上图中点击“Browser”按钮，选择maven路径下的settings.xml文件，settings.xml中配置的localRepository项的值就会显示在下面；

c) 运行参数配置:

 

 

选择jdk项，点击“编辑”按钮，在下面的缺省VM参数里面输入：

-Dmaven.multiModuleProjectDirectory=$M2_HOME

4、经常使用命令：

 

5、生命周期：

一、 Maven有三个内嵌的生命周期：clean是删除target目录中以前生成的.class和.jar等文件；default是默认生命周期,负责项目的编译和打包; site关注的是为项目生成文档,实际上site能够为项目生成一个网页式的文档。

二、 每个生命周期被分为一系列的构建阶段，构建阶段又被分为一系列的构建目标。所以，整个构建过程由一系列的生命周期、构建阶段和构建目标组成。

三、 你能够执行一个生命周期，如clean或site，一个构建阶段，如default生命期的install，或者一个构建目标，如dependency:copy-dependencies。注意：你不能直接执行default生命期，你须要指定default生命期中的一个构建阶段或者构建目标。

四、 将构建阶段的名称做为参数传给mvn命令，就是执行该构建阶段，如：mvn package。

(一) Clean清理项目：

a) pre-clean 执行清理前的工做

b) clean 清理上一次构建生成的全部文件

c) post-clean 执行清理后的文件

(二) Default构建项目：

d) compile 编译项目中的源代码；

e) test 使用合适的单元测试框架进行测试，这些测试代码不会被打包或部署；

f) test-compile 将须要测试的源代码编译到路径，通常是编译src/test/java目录下的java文件至目标输出的测试classpath目录中；

g) package 接受编译好的代码，打包成可发布的格式，如JAR；

h) install 将包安装到本地仓库，给其余本地引用提供依赖；

(三) Site生成项目站点：

i) pre-site 在生成项目站点前要完成的工做；

j) site 生成项目的站点文档；

k) post-site 在生成项目站点后要完成的工做；

l) site-deploy 发布生成的站点到服务器上；

6、新建maven项目：

一、新建maven工程：

 

二、选择工程类型 (Version -RELEASE)：

 

三、输入工程信息：

 

 

 

四、运行项目：

 

单击右键项目"run as"--->maven build，在Navigator视图下能够看到target目录下有文件了。

注意：若是运行时提示“No goals have been specified for this build…………”，则须要打开运行配置窗口，而后在Goals中输入“compile”就行：

7、POM文件：

 

 

 

 

一、dependencyManagement与dependencies的区别：

dependencies：全部声明在父项目中 dependencies 里的依赖都会被子项目自动引入，并默认被全部的子项目继承。即便在子项目中不写该依赖项，那么子项目仍然会从父项目中继承该依赖项（所有继承）

dependencyManagement ：只是声明依赖，并不实现引入，所以子项目须要显示的声明须要用的依赖。若是不在子项目中声明依赖，是不会从父项目中继承下来的；只有在子项目中写了该依赖项，而且没有指定具体版本，才会从父项目中继承该项，而且 version 和 scope 都读取自父 pom; 另外若是子项目中指定了版本号，那么会使用子项目中指定的jar版本。

好比以下配置：

首先在父POM中定义：

1 <properties> 2 <javaee-api.version>1.0-SNAPSHOT</javaee-api.version> 3 </properties> 4 <dependencyManagement> 5 <dependencies>  6 <dependency>  7 <groupId>javax</groupId>  8 <artifactId>javaee-api</artifactId>  9 <version>${javaee-api.version}</version>  10 </dependency>  11 </dependencies> 12 </dependencyManagement>

接着在子POM中定义以下：

1 <parent>  2 <artifactId>parent</artifactId>  3 <groupId>com.zhisheng</groupId> 4 <version>0.0.1-SNAPSHOT</version>  5 </parent> 6 <dependencies>  7 <dependency>  8 <groupId>javax</groupId>  9 <artifactId>javaee-api</artifactId>  10 </dependency>  11 </dependencies>

二、plugins与dependencyManagement的区别：

pluginManagement是表示插件声明，即你在项目中的pluginManagement下声明了插件，Maven不会加载该插件，pluginManagement声明能够被继承。pluginManagement通常是用来在父POM中定义，提供给子POM使用，子POM也能够覆盖这个定义，并且你在父POM中定义了版本以后，子模块中直接应用groupId和artifactId，而不用指定版本，同时也方便统一管理；而在父POM中的pluginManagement并不会介入到Maven的生命周期。pluginManagement主要是为了统一管理插件，确保全部子POM使用的插件版本保持一致，相似dependencies和dependencyManagement。

Plugins：就是直接引入一个plugin，并且能够绑定到Maven相关的生命周期上。

8、依赖管理：

一、假设你的项目依赖于一个库，而这个库又依赖于其余库。你没必要本身去找出全部这些依赖，你只须要加上你直接依赖的库，Maven会隐式的把这些库间接依赖的库也加入到你的项目中。

二、传递性依赖的嵌套深度没有任何限制，只是在出现循环依赖时会报错。

三、“短路径优先”意味着项目依赖关系树中路径最短的版本会被使用。例如，假设A、B、C之间的依赖关系是A->B->C->D(2.0)和A->E->(D1.0)，那么D(1.0)会被使用，由于A经过E到D的路径更短。但若是你想要强制使用D(2.0)，那你也能够在A中显式声明对D(2.0)的依赖。

四、依赖范围 – 你能够指定只在当前编译范围内包含合适的依赖。

　　a) Compile：这是默认范围。若是没有指定，就会使用该依赖范围。编译依赖对项目全部的classpath均可用。此外，编译依赖会传递到依赖的项目。

　　b) Provided：和compile范围很相似，但provided范围代表你但愿由JDK或者某个容器提供运行时依赖。例如，当使用Java EE构建一个web应用时，你会设置对Servlet API和相关的Java EE APIs的依赖范围为provided，由于web容器提供了运行时的依赖。provided依赖只对编译和测试classpath有效，而且不能传递。

　　c) runtime：runtime范围代表编译时不须要依赖，而只在运行时依赖。此依赖范围对运行和测试classpath有效，对编译classpath无效。

　　d) test：test范围代表使用此依赖范围的依赖，只在编译测试代码和运行测试的时候须要，应用的正常运行不须要此类依赖。

　　e) system：系统范围与provided相似，不过你必须显式指定一个本地系统路径的JAR，此类依赖应该一直有效，Maven也不会去仓库中寻找它。

　　f) import（Maven2.0.9及以上）：import范围只适用于pom文件中的部分。代表指定的POM必须使用部分的依赖。由于依赖已经被替换，因此使用import范围的依赖并不影响依赖传递。

五、排除依赖 – 若是项目X依赖于项目Y，项目Y又依赖项目Z，项目X的全部者可使用”exclusion”元素来显式排除项目Z。

六、可选依赖 – 若是项目Y依赖项目Z，项目Y的全部者可使用”optional”元素来指定项目Z做为X的可选依赖。那么当项目X依赖项目Y时，X只依赖Y并不依赖Y的可选依赖Z。项目X的全部者也能够根据本身的意愿显式指定X对Z的依赖。（你能够把可选依赖理解为默认排除）。

(一) 项目依赖：

项目A依赖项目B,项目B依赖项目C.众多的项目造成一个有向无环图(DAG)，使用maven,就能够自动推导出项目所依赖的所有jar包。

在pom.xml中进行以下配置：

1 <dependencies> 2 <dependency> 3 <groupId>org.jsoup</groupId> 4 <artifactId>jsoup</artifactId> 5 <version>1.7.1</version> 6 </dependency> 7 <dependency> 8 <groupId>junit</groupId> 9 <artifactId>junit</artifactId> 10 <version>4.8.1</version> 11 <scope>test</scope> 12 </dependency> 13 </dependencies>

(二) 外部依赖：

有时只有一个jar包而没有它的groupId和artifactId,而且三种maven仓库中都没有这个jar包项目,但当前项目依赖这个jar包,这种依赖叫作外部依赖。

有两个方法解决：

一、在每一个maven项目的pom.xml文件中以下配置：

1 <dependency> 2 <groupId>mydependency</groupId> 3 <artifactId>mydependency</artifactId> 4 <scope>system</scope> 5 <version>1.0</version>  6 <systemPath>${basedir}\mydependency.jar</systemPath> 7 </dependency>

二、方法一太过麻烦，能够将第三方jar包安装到本地maven仓库中去：

mvn install:install-file -Dfile=xxx -DgroupId=xxx -DartifactId=xxx -Dversion=xxx -Dpackaging=xxx

其中packaging是打包类型,能够取值war,jar等。

若是第三方jar包有相应的pom.xml,则没必要提供groupId,artifactId等信息,由于它们都在pom.xml里面写着呢.可使用以下命令：

mvn install:install-file -Dfile=xxx -DpomFile=xxx

(三) 快照依赖：

快照依赖指的是那些还在开发中的依赖（jar包）。与其常常地更新版本号来获取最新版本，不如你直接依赖项目的快照版本。快照版本的每个build版本都会被下载到本地仓库，即便该快照版本已经在本地仓库了。老是下载快照依赖能够确保本地仓库中的每个build版本都是最新的。

在pom文件的最开头的版本号后追加-SNAPSHOT，则告诉Maven你的项目是一个快照版本。如：

<version>1.0-SNAPSHOT</version>

在配置依赖时，在版本号后追加-SNAPSHOT代表依赖的是一个快照版本。

9、Maven工程类型：

Maven工程类型有三种：

一、WAR包工程；

二、JAR包工程；

三、POM工程；

工程之间的关系：

一、依赖：经过在 dependencies 元素下添加 dependency 子元素，能够声明一个或多个依赖。

依赖是具备传递性的。

二、聚合：一个项目每每是由多个 project 构成的，在进行构建时，咱们固然不想针对多个 project 分别执行屡次构建命令，这样极容易产生遗漏也会大大下降效率。Maven的聚合功能能够经过一个父模块将全部的要构建模块整合起来，将父模块的打包类型声明为 POM，经过 <modules> 将各模块集中到父 POM 中。配置以下：

1 <modules>  2 <module>../com.dugeng.project1</module> 3 <module>../com.dugeng.project2</module> 4 </modules>

父类型的模块，不须要有源代码和资源文件，也就是说，没有 src/main/java 和 src/test/java 目录。Maven 会首先解析聚合模块的 POM 文件，分析要构建的模块，并经过各模块的依赖关系计算出模块的执行顺序，根据这个潜在的关系依次构建模块。将各子模块聚合到父模块中后，咱们就能够对父模块进行一次构建命令来完成所有模块的构建。

三、继承：经过构建父模块将子模块共用的依赖，插件等进行统一声明。

例如将 com.dugeng.parent 这个模块声明为 project1 和 project2 的父模块，那么咱们在 project1 和 2 中用以下代码声明父子关系：

1 <parent> 2 <groupId>com.dugeng.mavenproject</groupId> 3 <artifactId>com.dugeng.parent</artifactId> 4 <version>0.0.1-SNAPSHOT</version> 5 <relativePath>../com.dugeng.parent/pom.xml</relativePath> 6 </parent>

因为父模块只是用来声明一些可共用的配置和插件信息，因此它也像聚合模块同样只须要包括一个 POM 文件，其它的项目文件如 src/main/java 是不须要的。

父工程应该是一个POM工程；