maven 技术

转自http://www.cnblogs.com/alipayhutu/archive/2012/08/16/2643098.html

 

 

 mvn命令若干：

mvn -h，不会用时，可寻求帮助。

mvn clean compile，将.java类编译为.class文件；

mvn clean test, 执行单元测试。本质上，还是执行了一个完整的生命周期，clean:clean, resources:resources, compiler:compile, resources:testResources, compiler:testCompile

mvn clean package，进行打包。

mvn clean install –Dmaven.test.skip

mvn clean install，将某jar包安装到maven本地仓库中。

mvn archetype:generate，快速的搭建项目骨架，输入一些groupId/artifactId/version等信息，由mvn插件自动生成一些必要的依赖和项目骨架。

package:    命令完成了项目编译、单元测试、打包功能，但没有把打好的可执行jar包（war包或其它形式的包）布署到本地       maven仓库和远程maven私服仓库
install:    命令完成了项目编译、单元测试、打包功能，同时把打好的可执行jar包（war包或其它形式的包）布署到本地maven仓库，但没有布署到远程maven私服仓库
deploy:   命令完成了项目编译、单元测试、打包功能，同时把打好的可执行jar包（war包或其它形式的包）布署到本地maven仓库和远程maven私服仓库
 

 

 这三个标签，形成一个小单元（所谓的依赖的“基本坐标”）

<groupId>, 定义组，如com.googlecode.myapp

<artifactId>, 定义组内一个具体的条目，如helloworld。（com.googlecode.myapp.helloworld）

<version>，定义个版本号。一般开发中的包，1.0-SNAPSHOT即用snapshot作为后缀。

 以下为非必须（但要了解）：

<type> ，package类型，一般不用写，默认是jar。还有，jar/war/pom/maven-plugin/ear等。

<scope>，依赖范围，我简记为“能见度”。例如，

test=测试。仅对测试类有效，在java类中引入会报错的。例如，JUnit

compile=编译+测试+运行，默认不写则是这种编译方式，对于编译、测试、运行都有效。例如，spring-core

provided=编译+测试。对于编译和测试有效，运行时无效。例如，servlet-api，其在编译和测试时需要使用，但在运行时由于容器已经提供，所以不需要mvn重新的引入一遍。

runtime=运行时。例如，JDBC驱动实现，类的编译只需JDK提供的JDBC接口即可，在真正执行测试或运行时才需实现上述接口的具体JDBC驱动。

system=// 这个可以不用理解。

import=导入。

<optional>，可选依赖。例如，A->B，B->C（optional=true），那么A将对C不形成传递依赖。

<exclusions>，排除依赖。例如，A->B, B->C(1.0-SNAPSHOT)，而我实际想用C2.0，那么就需要在B中将C给排除出去。

 

 对于同一模块的jar包，可以在pom中通过统一变量进行定义

声明<properties><springframework.version>2.5.6</…>

引用<version>${springframework.version}</…>

 

 传递依赖（->表示依赖）：

A->B，而实际上，B->C，那么A对B是直接依赖，对C是传递依赖。其“能见度”如下表所示。第一列为A->B，对一行为B->C，表格中内容为，A->C。

	compile	test	provided	runtime
compile	compile	no	no	runtime
test	test	no	no	test
provided	provided	no	provided	provided
runtime	runtime	no	no	runtime

 

  依赖调解：

A->B->C->X(1.0)

A->D->X(2.0)

那么，按路径最短者生效（即X2.0）.

A->B->Y(1.0)

A->C->Y(2.0)

那么，mvn2.0.8及之前版本，顺序不确定。mvn2.0.9以后，第一声明者优先。

 

  如何查看依赖：

一个事实：mvn会自动解析所有项目的直接依赖和传递性依赖，并且根据一定规则正确判断每个依赖的范围，对于一些依赖冲突，也能进行调节，以确保任何一个构件只有唯一的版本在依赖中存在。在这些工作之后，最后得到的那些依赖被称为已解析依赖（Resolved Dependency）。

一个命令：mvn dependency:list

一个命令：mvn dependency:tree

一个命令：mvn dependency:analyze

 

==================以下为进阶===================

 

  生命周期：

public abstract class AbstractBuild(){

    public void build(){

          initialize(); // 初始化工作

          compile(); // 编译

          test();        // 测试

          package(); // 打包

          integrationTest(); // 集成测试

          deploy();  // 部署

    }

}

这里只是个示意，以说明maven存在的价值、意义和定位。其中的每个步骤，都可以用插件来做。mvn也为我们设置了默认的插件，不过如果想进行个性化的定制，可以自己选择plugin，或者自己写plugin。

1）以下三个生命周期，相互独立，且每个生命周期的每个步骤，均可单独调用（但假如调步骤3的时候，其前的步骤1、2也是会执行的）。

2）注意，在命令行执行mvn命令，本身就是在调用mvn的生命周期哦，可爱吧，呵呵。

clean生命周期

pre-clean

clean

post-clean

default生命周期（从上到下，从左至右的看哦）

validate	generate-sources	generate-test-sources	prepare-package	pre-interation-test
initialize	process-sources（注1）	process-test-sources	package（注4）	integration-test
	generate-resources	generate-test-resources		verify
	process-resources	process-test-resources		install（注5）
	compile（注2）	test-compile		deploy（注6）
	process-classes	process-test-classes
		test（注3）

注1：一般来说，对src/main/resources目录的内容进行变量替换等工作后，复制到项目输出的主classpath目录当中去。

注2：一般来说，是编译src/main/java目录下的java文件至项目输出的主classpath目录当中去。

注3：使用单元测试框架运行测试，测试代码不会被打包或部署。

注4：将编译好的代码，打包成可发布的格式，如jar。

注5：将包安装到mvn本地仓库，供本地其他mvn项目使用。

注6：将包复制到远程仓库。

 

site生命周期

暂略去不谈。

 

 

  认识插件：

 

1）在pom中，可自定义插件，并将其绑进生命周期中去。有些插件自己也会有默认的生命周期的，取决于插件自身实现。根据功能，也可以一个插件绑到N个阶段中去。

2）在pom中，可对插件进行全局配置，例如maven-compiler-plugin默认都用JDK 1.5进行。

 

其它参考http://maven.apache.org/pom.html

 

http://www.iteye.com/topic/973166

http://josh-persistence.iteye.com/blog/1874950

http://blueram.iteye.com/blog/1684070

http://blog.csdn.net/wanghantong/article/details/9375013

http://liugang594.iteye.com/blog/2093082

http://blog.csdn.net/meyoung01/article/details/10073135

http://maven.apache.org/surefire/maven-surefire-plugin/examples/single-test.html

https://maven.apache.org/guides/introduction/introduction-to-the-pom.html

http://zhaoshijie.iteye.com/blog/2094478