maven使用记要

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默认scopetest V 只在测试期依赖，如junit包providedVV 运行期由容器提供，如servlet-api包runtime VV编译期间不需要直接引用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/