maven基本知识

//意识

 

1 意义:

    (1)没有任何实际的Java代码，我们就能够定义一个Maven项目的POM，这体现了Maven的一大优点，它能让项目对象模型最大程度地与实际代码相独立，我们可以称之为解耦，或者正交性，这在很大程度上避免了Java代码和POM代码的相互影响。比如当项目需要升级版本时，只需要修改POM，而不需要更改Java代码；而在POM稳定之后，日常的Java代码开发工作基本不涉及POM的修改。

 

    (2)Maven强大的一个重要的原因是它有一个十分完善的生命周期模型(lifecycle)，这个生命周期可以从两方面来理解，第一，顾名思义，运行Maven的每个步骤都由它来定义的，这种预定义的默认行为使得我们使用Maven变得简单，相比而言，Ant的每个步骤都要你手工去定义。第二，这个模型是一种标准，在不同的项目中，使用Maven的接口是一样的，这样就不用去仔细理解每个项目的构建了

 

2 Maven生命周期

 

(1)

Maven有三套相互独立的生命周期，请注意这里说的是“三套”，而且“相互独立”，初学者容易将Maven的生命周期看成一个整体，其实不然。这三套生命周期分别是：

 

Clean Lifecycle 在进行真正的构建之前进行一些清理工作。

Default Lifecycle 构建的核心部分，编译，测试，打包，部署等等。

Site Lifecycle 生成项目报告，站点，发布站点。

 

我再次强调一下它们是相互独立的，你可以仅仅调用clean来清理工作目录，仅仅调用site来生成站点。当然你也可以直接运行 mvn clean install site 运行所有这三套生命周期

 

(2)clean

clean也算是一种习惯吧，它可以避免一些错误的发生。clean的主要功能是删除maven生成的target文件，如果不执行clean，而直接install的话，其过程中生成的如.class文件就会覆盖原来的文件，这在一般情况下是没有问题的。但是，比如你在源文件删除了一个java，结果没有clean，则它依然存在与target中，可能会对最终的结果造成影响

 

(3)

来看一下Maven的最重要的Default生命周期，绝大部分工作都发生在这个生命周期中，这里，我只解释一些比较重要和常用的阶段：(详细参考http://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html#Lifecycle_Reference)

 

validate

generate-sources

process-sources

generate-resources

process-resources     复制并处理资源文件，至目标目录，准备打包。

compile     编译项目的源代码。

process-classes

generate-test-sources 

process-test-sources 

generate-test-resources

process-test-resources     复制并处理资源文件，至目标测试目录。

test-compile     编译测试源代码。

process-test-classes

test     使用合适的单元测试框架运行测试。这些测试代码不会被打包或部署。

prepare-package

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

pre-integration-test

integration-test

post-integration-test

verify

install     将包安装至本地仓库，以让其它项目依赖。

deploy     将最终的包复制到远程的仓库，以让其它开发人员与项目共享

 

 

//配置解读

 

1 pom: 项目对象模型,定义了项目的基本信息，用于描述项目如何构建，声明项目依赖，等等

 

2 <modelVersion>4.0.0</modelVersion>: 根元素下的第一个子元素modelVersion指定了当前POM模型的版本，对于Maven2及Maven 3来说，它只能是4.0.0

 

3 groupId，artifactId, version: 这三个元素定义了一个项目基本的坐标，在Maven的世界，任何的jar、pom或者war都是以基于这些基本的坐标进行区分的

(1) groupId定义了项目属于哪个组，这个组往往和项目所在的组织或公司存在关联,如com.apusic.mq,也代表对应jar包等在maven repository中的目录结构.

(2) artifactId定义了当前Maven项目在组中唯一的ID,代表模块的名称,一般是项目名称,如apusic-mq-template,apusic-mq-container等,注意所有项目包括mq_project的父POM是artifactId为apusic-mq-template的POM,对应工程为apusic-mq-template,没有被导入Eclipse工程,被所有其他子模型所继承

(3)version指定了项目当前的版本

(4)有些pom文件还声明name元素,name元素声明了一个对于用户更为友好的项目名称,但这不是必须的

 

4 <dependency>  

       <groupId>junit</groupId>  

       <artifactId>junit</artifactId>  

       <version>4.7</version>  

       <scope>test</scope>  

 </dependency> 

值为test的元素scope，scope为依赖范围，若依赖范围为test则表示该依赖只对测试有效，换句话说，src/test/java测试代码中的import JUnit代码是没有问题的，但是如果我们在src/main/java主代码中用import JUnit代码，就会造成编译错误

 

 

 

//命令与操作解读:

 

1 mvn clean install:

将对应项目输出的jar/war等安装到Maven本地仓库中,这样就能让其他的Maven项目直接引用这个jar

 

2 mvn clean compile、mvn clean test、mvn clean package、mvn clean install

执行test之前是会先执行compile的，执行package之前是会先执行test的，而类似地，install之前会执行package

 

3 如果要打包能够运行的jar包,需要使用maven-shade-plugin插件

 

4 mvn archetype:generate 或 mvn org.apache.maven.plugins:maven-archetype-plugin:2.0-alpha-5:generate

Archetype插件将根据我们提供的信息创建项目骨架

 

5 在eclipse中创建Maven项目,m2eclipse实际上是在使用maven-archetype-plugin插件创建项目骨架

 

6 使用assembly plugin实现自定义打包:

http://www.blogjava.net/aoxj/archive/2009/01/16/251615.html

 

//本地仓库,远程仓库,镜像,分发构件至远程仓库

1 本地仓库: 运行Maven的时候，Maven所需要的任何构件都是直接从本地仓库获取的。如果本地仓库没有，它会首先尝试从远程仓库下载构件至本地仓库，然后再使用本地仓库的构件。

 

2 远程仓库: 

在POM中可配置远程仓库

(1)<repositories>: 可以在它下面添加多个<repository> ，每个<repository>都有它唯一的ID，一个描述性的name，以及最重要的，远程仓库的url。此外，<releases><enabled>true</enabled></releases>告诉Maven可以从这个仓库下载releases版本的构件，而<snapshots><enabled>false</enabled></snapshots>告诉Maven不要从这个仓库下载snapshot版本的构件。禁止从公共仓库下载snapshot构件是推荐的做法，因为这些构件不稳定，且不受你控制，你应该避免使用。当然，如果你想使用局域网内组织内部的仓库，你可以激活snapshot的支持

 

(2)<pluginRepositories>，这是配置Maven从什么地方下载插件构件（Maven的所有实际行为都由其插件完成）。该元素的内部配置和<repository>完全一样，不再解释

 

在settings.xml中配置远程仓库:

在settings.xml中配置远程仓库使用所有project可以共享配置,定义一个profile，将所有repositories以及pluginRepositories元素放到这个profile中，然后，使用<activeProfiles>元素自动激活该profile。这样，你就不用再为每个POM重复配置仓库。使用profile为settings.xml添加仓库提供了一种用户全局范围的仓库配置。

 

3 镜像

如果你的地理位置附近有一个速度更快的central镜像，或者你想覆盖central仓库配置，或者你想为所有POM使用唯一的一个远程仓库（这个远程仓库代理的所有必要的其它仓库），你可以使用settings.xml中的mirror配置。

以下的mirror配置用maven.net.cn覆盖了Maven自带的central：

Xml代码  

1. <settings>  
2. ...  
3.   <mirrors>  
4.     <mirror>  
5.       <id>maven-net-cn</id>  
6.       <name>Maven China Mirror</name>  
7.       <url>http://maven.net.cn/content/groups/public/</url>  
8.       <mirrorOf>central</mirrorOf>  
9.     </mirror>  
10.   </mirrors>  
11. ...  
12. </settings>  

 

这里唯一需要解释的是<mirrorOf>，这里我们配置central的镜像，我们也可以配置一个所有仓库的镜像，以保证该镜像是Maven唯一使用的仓库：

Xml代码  

1. <settings>  
2. ...  
3.   <mirrors>  
4.     <mirror>  
5.       <id>my-org-repo</id>  
6.       <name>Repository in My Orgnization</name>  
7.       <url>http://192.168.1.100/maven2</url>  
8.       <mirrorOf>*</mirrorOf>  
9.     </mirror>  
10.   </mirrors>  
11. ...  
12. </settings>  

镜像是用来取代某个或全部远程库的,当远程库配置在pom文件,而在本机的Settings文件中配置了远程库的镜像后,那么将使用镜像而不使用远程库

 

4 分发构件至远程仓库

mvn install 会将项目生成的构件安装到本地Maven仓库，mvn deploy 用来将项目生成的构件分发到远程Maven仓库。本地Maven仓库的构件只能供当前用户使用，在分发到远程Maven仓库之后，所有能访问该仓库的用户都能使用你的构件。我们需要配置POM的distributionManagement来指定Maven分发构件的位置

 

Maven区别对待release版本的构件和snapshot版本的构件，snapshot为开发过程中的版本，实时，但不稳定，release版本则比较稳定。Maven会根据你项目的版本来判断将构件分发到哪个仓库。

一般来说，分发构件到远程仓库需要认证，如果你没有配置任何认证信息，你往往会得到401错误。这个时候，在settings.xml <servers>中配置认证信息,注意ID要和POM的distributionManagement中的对应