maven使用记要

朱雀 2022-04-21 15:31 133阅读 0赞

**maven生命周期**

maven的生命周期包含超过20多个阶段,以下是最主要的阶段,按顺序排列:

*  Validate: validates that all project information is available and is correct
 *  Compile: compiles the source code
 *  Test: runs unit tests within a suitable framework
 *  Package: packages the compiled code in its distribution format
 *  Integration-test: processes the package in the integration-test environment
 *  Verify: runs checks to verify that the package is valid
 *  Install: installs the package in the local repository
 *  Deploy: installs the final package in a remote repository

记住，运行任何一个阶段的时候，它前面的所有阶段都会被运行，这也就是为什么我们运行mvn install 的时候，代码会被编译，测试，打包。 Maven的插件机制是完全依赖Maven的生命周期的。

**maven依赖**

maven的依赖关系有6个范围:

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

每个工程都有一个打包类型，可以是jar, war, ear 或 pom。打包类型决定了工程最终产物的类型。 其中pom类型用于构件多模块工程。

依赖,可在父节点的pom文件中指定,然后能够被子节点需要的时候继承.如对于依赖包的版本号的指定,如在父节点中有指定,在子节点中可不指定,子节点将使用父节点的设定值,这样可避免版本号冲突问题.

**dependencies 和 dependencyManagement 的区别在于**：  
前者，即使在子项目中不写该依赖项，那么子项目仍然会从父项目中继承该依赖项。  
后者，如果在子项目中不写该依赖项，那么子项目中是不会从父项目继承该依赖项的；只有在子项目中写了该依赖项，才会从父项目中继承该项，并且version 和 scope 都读取自 父pom。

工程之间有两种关系：依赖和聚合。

1.1 工程依赖关系  
依赖关系的管理是maven最为人称道的地方。一个工程可以依赖多个其他工程， 通过工程的唯一标识（groupId+artifactId+version)可以明确指明依赖的库及版本，而且能够处理 依赖关系的传递。 maven可以指定依赖的作用范围（scope），包括以下几种：  
  
scope编译期测试期运行期说明\*compileVVV默认scopetestV只在测试期依赖，如junit包providedVV运行期由容器提供，如servlet-api包runtimeVV编译期间不需要直接引用systemVV编译和测试时由本机环境提供  
  
1.2 工程聚合关系  
前面提到pom类型用于于构件多模块工程，这体现了project之间的一种聚合关系： 将一系列小的模块聚合成整个产品。  
  
  
通过聚合后的工程可以同时管理每个相关模块的构建、清理、文档等工作。 聚合关系通过在子工程中指定一个pom类型的project作为父project来定义。

**Maven变****量**

Maven内置变量说明：

*  $\{basedir\} 项目根目录
 *  $\{version\} 相当于$\{project.version\}
 *  $\{project.build.directory\} 构建目录，缺省为target
 *  $\{project.build.outputDirectory\} 构建过程输出目录，缺省为target/classes
 *  $\{project.build.finalName\} 产出物名称，缺省为$\{project.artifactId\}-$\{project.version\}
 *  $\{project.packaging\} 打包类型，缺省为jar
 *  $\{project.xxx\} 当前pom文件的任意节点的内容

Maven提供了一些隐式的变量可以用来访问环境变量，POM信息，和Maven Settings等:

*  env : env变量，暴露了你操作系统或者shell的环境变量。便 如在Maven POM中一个对$\{env.PATH\}的引用将会被$\{PATH\}环境变量替换，在Windows中为%PATH%.
 *  projetc : project变量暴露了POM。可以使用点标记(.)的路径来引用POM元素的值。
 *  settings : settings变量暴露了Maven settings信息。可以使用点标记(.)的路径来引用settings.xml文件中元素的值。例如$\{settings.offline\}会引用~/.m2/settings.xml文件中offline元素的值。

**Profile**

在开发项目时，设想有以下场景：你的Maven项目存放在一个远程代码库中（比如github），该项目需要访问数据库，你有两台电脑，一台是Linux，一台是Mac OS X，你希望在两台电脑上都能做项目开发。但是，安装Linux的电脑上安装的是MySQL数据库，而Mac OS X的电脑安装的是PostgreSQL数据库。此时你需要找到一种简单的方法在两种数据库连接中进行切换，你会怎么做？  
此外，你的项目需要部署。为了调试，在开发时我们在Java编译结果中加入了调试信息（Java默认）。而在部署时你希望Java编译结果中不出现调试信息。此时你又会怎么做？  
  
答案是Profile。Maven的Profile用于在不同的环境下应用不同的配置。一套配置即称为一个Profile。这里的“环境”可以是操作系统版本，JDK版本或某些文件是否存在这样的物理环境，也可以是你自己定义的一套逻辑环境。比如上面的A中所说的Linux和Mac OS X便是一种物理环境，而B中讲的开发环境和部署环境则为逻辑环境。Maven提供了Activation机制来激活某个Profile，它既允许自动激活（即在某些条件满足时自动使某个Profile生效），也可以手动激活。  
  
一个Profile几乎可以包含所有能够出现在pom.xml中的配置项，比如<artifactId>，<outputDirectory>等。相当于**在Profile中定义的配置信息会覆盖原有pom.xml中的相应配置项**。

**Eclipse中增强对maven的支持**

安装上m2e-wtp: http://www.eclipse.org/m2e-wtp/