Maven 实战1

骑着上帝去环游

浏览: 46715 次
性别:
来自: 北京

最近访客更多访客>>

我的无奈

kiss_acm

xby1099687785

追求卓绝

博主相关

博客

微博

相册

留言

关于我

文章分类

社区版块

存档分类

博客分类：

Maven

Maven实战（一）安装和配置

1. 简介

Maven是基于项目对象模型(POM)，可以通过一小段描述信息来管理项目的构建，报告和文档的软件项目管理工具.
　如果你已经有十次输入同样的Ant targets来编译你的代码、jar或者war、生成javadocs，你一定会自问，是否有一个重复性更少却能同样完成该工作的方法。 Maven便提供了这样一种选择，将你的注意力从作业层转移到项目管理层。Maven项目已经能够知道如何构建和捆绑代码，运行测试，生成文档并宿主项目网页

2.核心价值

   * 简单
      Maven 暴露了一组一致、简介的操作接口，能帮助团队成员从原来的高度自定义的、复杂的构建系统中解脱出来，使用Maven现有的成熟的、稳定的组件也能简   化构建系统的复杂度。

   * 交流与反馈
      与版本控制系统结合后，多有人都能执行最新的构建并快速得到反馈。此外，自动生成的项目报告也能帮助成员了解项目的状态，促进团队的交流。

   * 测试驱动开发
      TDD强调测试先行，所有产品都应该由测试用例覆盖。而测试是maven生命周期的最重要组成部分之一，并且Maven有现成的成熟插件支持业界流行的测试框架，如Junit和TestNG。

   * 快速构建
    只需要一些配置，之后用一条简单的命令就能让Maven帮你清理、编译、测试、打包、部署，然后得到最终产品。[/size]

   * 持续集成
      更加方便的持续集成

   * 富有信息的工作区

2.主要内容

   我将会发表一系列课程来讲解Maven的应用，基于Maven3.0，主要内容如下：

   1）安装和配置

   2）Maven使用入门

   3）坐标和依赖

   4）Maven仓库

   5) 生命周期和插件

   6）聚合与继承

   7）使用Nexus创建私服

   8）使用Maven进行测试

   9）m2eclipse的使用

   10）自动部署maven项目

   11）使用Hudson进行持续集成

3. 安装好JDK

    以JDK1.5以上为例

4. Maven 的下载
   下载地址：http://maven.apache.org/download.html

5.Maven安装

   将下载到的文件解压到指定目录即可，如：C:\maven\apache-maven-3.0.4

6.环境变量的配置

    在系统环境变量中新增如下环境变量
    M2_HOME: Maven的安装目录，如：C:\maven\apache-maven-3.0.4
    M2: %M2_HOME%\bin
    并在path中添加%M2%，这样便可以在任何路径中执行mvn命令

7. 检测安装是否成功

    Cmd窗口执行命令：mvn –v
    得到如下图所示结果：

8.设置代理

有时候你所在的公司基于安全因素考虑，要求你使用通过安全认证的代理访问因特网。这时就需要为Maven配置HTTP代理。

在目录~/.m2/setting.xml文件中编辑如下（如果没有该文件，则复制$M2_HOME/conf/setting.xml）：

Xml代码

<proxies>
<proxy>
<id>optional</id>
<active>true</active>
<protocol>http</protocol>
<username>proxyuser</username>
<password>proxypass</password>
<host>proxy.host.net</host>
<port>80</port>
<nonProxyHosts>local.net|some.host.com</nonProxyHosts>
</proxy>
</proxies>

Maven实战（二）构建简单Maven项目

上一节讲了maven的安装和配置，这一节我们来学习一下创建一个简单的Maven项目

1. 用Maven 命令创建一个简单的Maven项目

在cmd中运行如下命令：

Cmd代码

mvn archetype:generate
-DgroupId=com.mycompany.app
-DartifactId=my-app-simple
-Dversion=1.0
-DarchetypeArtifactId=maven-archetype-quickstart

即可在当前目录创建一个简单的maven项目，当然创建的时候会从Maven库中下载相关的依赖，耐心等待即可。

maven的大致结构如下：

Java代码

my-app
|-- pom.xml
`-- src
|-- main
| |-- java
| | `-- com
| | `-- mycompany
| | `-- app
| | `-- App.java
| `-- resources
| `-- META-INF
| `-- application.properties
`-- test
`-- java
`-- com
`-- mycompany
`-- app
`-- AppTest.java

src/main/java : java源文件存放位置

src/main/resource : resource资源，如配置文件等

src/test/java : 测试代码源文件存放位置

2.简单POM.xml

打开项目即可看到pom.xml

Xml代码

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>com.mycompany.app</groupId>
<artifactId>my-app-simple</artifactId>
<packaging>jar</packaging>
<version>1.0</version>
<name>my-app-simple</name>
<url>http://maven.apache.org</url>
<dependencies>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>3.8.1</version>
<scope>test</scope>
</dependency>
</dependencies>
</project>

这段代码中最重要的是包含groupId, artifactId 和 version 的三行。这三个元素定义了一个项目基本的坐标

groupId 定义了项目属于哪个组，这个组往往和项目所在的组织或公司存在关联。譬如在googlecode上建立了一个名为myapp的项目，那么groupId就应该是com.googlecode.myapp

artifactId 定义了当前Maven项目在组织中唯一的ID, 可以理解为项目中的模块, 模块为Maven中最小单位构件

version 项目的版本

3.运行简单Maven命令

我们已经创建了最简单的Maven项目，下面我们来执行一些简单的构建命令

编译： compile

在cmd中，将目录切换到my-app-simple下，执行mvn clean compile

build success之后我们会在my-app-simple下看到新增了一个target目录，该目录下存放项目编译后的文件，如.class文件

清理： clean

cmd目录my-app-simple下执行命令 mvn clean

会将target文件删除，即清理项目，该命令可以结合其他命令运行

测试: test

cmd目录my-app-simple下执行命令 mvn test

会执行src/test/java 下的Junit 测试代码

当然在执行测试之前会自动执行编译命令，运行结果如下图：

打包: package

cmd目录my-app-simple下执行命令 mvn package

会将项目打成jar包，并放在target目录中

执行此命令之前会先执行编译和测试命令

安装：install

cmd目录my-app-simple下执行命令 mvn install

会将项目jar包安装到本地仓库中，以便其他项目使用

执行此命令之前会先执行编译，测试，打包命令

（三）Eclipse构建Maven项目

1. 安装m2eclipse插件
要用Eclipse构建Maven项目，我们需要先安装meeclipse插件
点击eclipse菜单栏Help->Eclipse Marketplace搜索到插件Maven Integration for Eclipse 并点击安装即可，如下图：

安装成成之后我们在Eclipse菜单栏中点击File->New->Other,在弹出的对话框中会看到如下图所示：

2. 构建Maven项目

以eclipse3.6为例

1）创建简单Maven项目

点击Eclipse菜单栏File->New->Ohter->Maven得到如下图所示对话框：

选中Maven Project并点击Next，到下一个对话框继续点击Next得到如下对话框

如图示操作，选择maven-archetype-quickstart，点击Next

按图示填写好groupId, artfactId,version等信息，点击Finish。

由此我们成功创建了一个简单的Maven项目，项目结构如图所示

2）创建Maven web项目

操作跟创建简单Maven项目类似，点击Eclipse菜单File->New->Other->Maven->Maven Project

在选择maven-archetype的界面进行如下操作：

点击Next,填写好相应的groupId,artifactId,version等信息，点击Finish

得到的Maven web项目结构如下图所示：

右击项目，点击Properties->Project Facets

如上图可以看到项目为web2.3 java1.5 当然我们也可以改成我们所需要的版本，打开xml文件my-app-web/.settings/org.eclipse.wst.common.project.facet.core.xml，进行修改即可：

Xml代码

<?xml version="1.0" encoding="UTF-8"?>
<faceted-project>
<fixed facet="wst.jsdt.web"/>
<installed facet="java" version="1.5"/>
<installed facet="jst.web" version="2.3"/>
<installed facet="wst.jsdt.web" version="1.0"/>
</faceted-project>

3）导入Maven项目

在Eclipse project explorer中右击，在弹出框中选择import，得到如下图所示：

选择Existing Maven Projects，并点击Next，得到如下图所示对话框：

选择一个已经创建好的Maven项目，并点击Finish。

由此，导入Maven项目成功

3. 运行Maven命令

右击项目，点击Run as，如下图：

即可看到有很多现有的maven命令，点击即可运行，并在控制台可以看到运行信息

如果你想运行的maven命令在这里没有找到，点击Maven build创建新的命令，操作如下图所示：

如下图填入Maven命令，点击Run即可

新增的maven命令可以通过如下方式找到，并再次运行：

Maven实战（四）生命周期

1. 三套生命周期
Maven拥有三套相互独立的生命周期，它们分别为clean，default和site。
每个生命周期包含一些阶段，这些阶段是有顺序的，并且后面的阶段依赖于前面的阶段，用户和Maven最直接的交互方式就是调用这些生命周期阶段。
以 clean生命周期为例，它包含的阶段有pre-clean, clean 和 post clean。当用户调用pre-clean的时候，只有pre-clean得以执行，当用户调用clean的时候，pre-clean和clean阶段会得以顺序执行；当用户调用post-clean的时候，pre-clean,clean,post-clean会得以顺序执行。

较之于生命周期阶段的前后依赖关系，三套生命周期本身是相互独立的，用户可以仅仅调用clean生命周期的某个阶段，或者仅仅调用default生命周期的某个阶段，而不会对其他生命周期产生任何影响。

2. clean 生命周期

clean生命周期的目的是清理项目，它包含三个阶段：

1）pre-clean 执行一些清理前需要完成的工作。

2）clean 清理上一次构建生成的文件。

3）post-clean 执行一些清理后需要完成的工作。

3. default 生命周期

default生命周期定义了真正构件时所需要执行的所有步骤，它是生命周期中最核心的部分，它包含的阶段如下：

1） validate 验证项目是否正确和所有需要的相关资源是否可用

2） initialize 初始化构建

3） generate-sources

4) process-sources 处理源代码

5） generate-resources

6) process-resources 处理项目主资源文件。对src/main/resources目录的内容进行变量替换等工作后，复制到项目输出的主classpath目录中。

7） compile 编译项目的主源代码

8） process-classes

9) generate-test-sources

10) process-test-sources 处理项目测试资源文件

11）generate-test-resources

12) process-test-resources 处理测试的资源文件

13）test-compile 编译项目的测试代码

14）process-test-classes

15) test 使用单元测试框架运行测试，测试代码不会被打包或部署

16）prepare-package 做好打包的准备

17）package 接受编译好的代码，打包成可发布的格式

18) pre-integration-test

19) integration-test

20) post integration-test

21) verify

22) install 将包安装到Maven本地仓库，供本地其他Maven项目使用

23）deploy 将最终的包复制到远程仓库，供其他开发人员和Maven项目使用

4. site 生命周期

site生命周期的目的是建立和发布项目站点，Maven能够基于POM所包含的信息，自动生成一个友好的站点，方便团队交流和发布项目信息。该生命周期包含如下阶段：

1）pre-site 执行一些在生成项目站点之前需要完成的工作

2）site 生成项目站点文档

3）post-site 执行一些在生成项目站点之后需要完成的工作

4）site-deploy 将生成的项目站点发布到服务器上

Maven实战（五）坐标详解

1.为什么要定义Maven坐标
在我们开发Maven项目的时候，需要为其定义适当的坐标，这是Maven强制要求的。在这个基础上，其他Maven项目才能应用该项目生成的构件。

2.Maven坐标详解

Maven坐标为各种构件引入了秩序，任何一个构件都必须明确定义自己的坐标，而一组Maven坐标是通过一些元素定义的，它们是groupId,artifactId,version,packaging,class-sifer。下面是一组坐标定义：

Xml代码

<groupId>com.mycompany.app</groupId>
<artifactId>my-app</artifactId>
<packaging>jar</packaging>
<version>0.0.1-SNAPSHOT</version>

下面讲解一下各个坐标元素：

groupId ：定义当前Maven项目隶属的实际项目。首先，Maven项目和实际项目不一定是一对一的关系。比如SpringFrameWork这一实际项目，其对应的Maven项目会有很多，如spring-core,spring-context等。这是由于Maven中模块的概念，因此，一个实际项目往往会被划分成很多模块。其次，groupId不应该对应项目隶属的组织或公司。原因很简单，一个组织下会有很多实际项目，如果groupId只定义到组织级别，而后面我们会看到，artifactId只能定义Maven项目（模块），那么实际项目这个层次将难以定义。最后，groupId的表示方式与Java包名的表达方式类似，通常与域名反向一一对应。

artifactId : 该元素定义当前实际项目中的一个Maven项目（模块），推荐的做法是使用实际项目名称作为artifactId的前缀。比如上例中的my-app。

version : 该元素定义Maven项目当前的版本

packaging ：定义Maven项目打包的方式，首先，打包方式通常与所生成构件的文件扩展名对应，如上例中的packaging为jar,最终的文件名为my- app-0.0.1-SNAPSHOT.jar。也可以打包成war, ear等。当不定义packaging的时候，Maven 会使用默认值jar

classifier: 该元素用来帮助定义构建输出的一些附件。附属构件与主构件对应，如上例中的主构件为my-app-0.0.1-SNAPSHOT.jar,该项目可能还会通过一些插件生成如my-app-0.0.1-SNAPSHOT-javadoc.jar,my-app-0.0.1-SNAPSHOT- sources.jar, 这样附属构件也就拥有了自己唯一的坐标

Maven实战（六）依赖

我们项目中用到的jar包可以通过依赖的方式引入，构建项目的时候从Maven仓库下载即可。

1. 依赖配置
依赖可以声明如下：

Xml代码

<project>
...
<dependencies>
<dependency>
<groupId>group-a</groupId>
<artifactId>artifact-a</artifactId>
<version>1.0</version>
<exclusions>
<exclusion>
<groupId>group-c</groupId>
<artifactId>excluded-artifact</artifactId>
</exclusion>
</exclusions>
</dependency>
<dependency>
<groupId>group-a</groupId>
<artifactId>artifact-b</artifactId>
<version>1.0</version>
<type>bar</type>
<scope>runtime</scope>
</dependency>
</dependencies>
</project>

我们在Maven实战(二)中就遇到了依赖的概念，项目中测试需要依赖junit jar包，依赖配置如下：

Xml代码

<dependencies>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>3.8.1</version>
<scope>test</scope>
</dependency>
</dependencies>

依赖会包含基本的groupId, artifactId,version等元素，根元素project下的dependencies可以包含一个或者多个dependency元素，以声明一个或者多个依赖。
下面详细讲解每个依赖可以包含的元素：

groupId,artifactId和version：依赖的基本坐标，对于任何一个依赖来说，基本坐标是最重要的，Maven根据坐标才能找到需要的依赖

type: 依赖的类型，对应于项目坐标定义的packaging。大部分情况下，该元素不必声明，其默认值是jar

scope: 依赖的范围，下面会进行详解

optional: 标记依赖是否可选

exclusions: 用来排除传递性依赖，下面会进行详解

大部分依赖声明只包含基本坐标。

2. 依赖范围

Maven在编译主代码的时候需要使用一套classpath,在编译和执行测试的时候会使用另一套classpath,实际运行项目的时候，又会使用一套classpath。

依赖范围就是用来控制依赖与这三种classpath(编译classpath、测试classpath、运行classpath)的关系，Maven有以下几种依赖范围：

compile: 编译依赖范围。如果没有指定，就会默认使用该依赖范围。使用此依赖范围的Maven依赖，对于编译、测试、运行三种classpath都有效。

test: 测试依赖范围。使用此依赖范围的Maven依赖，只对于测试classpath有效，在编译主代码或者运行项目的使用时将无法使用此类依赖。典型的例子就是JUnit，它只有在编译测试代码及运行测试的时候才需要。

provided: 已提供依赖范围。使用此依赖范围的Maven依赖，对于编译和测试classpath有效，但在运行时无效。典型的例子是servlet-api，编译和测试项目的时候需要该依赖，但在运行项目的时候，由于容器已经提供，就不需要Maven重复地引入一遍。

runtime: 运行时依赖范围。使用此依赖范围的Maven依赖，对于测试和运行classpath有效，但在编译主代码时无效。典型的例子是JDBC驱动实现，项目主代码的编译只需要JDK提供的JDBC接口，只有在执行测试或者运行项目的时候才需要实现上述接口的具体JDBC驱动。

system: 系统依赖范围。该依赖与三种classpath的关系，和provided依赖范围完全一致。但是，使用system范围依赖时必须通过 systemPath元素显式地指定依赖文件的路径。由于此类依赖不是通过Maven仓库解析的，而且往往与本机系统绑定，可能造成构建的不可移植，因此应该谨慎使用。systemPath元素可以引用环境变量，如：

Xml代码

<dependency>
<groupId>javax.sql</groupId>
<artifactId>jdbc-stdext</artifactId>
<version>2.0</version>
<scope></scope>
<systemPath>${java.home}/lib/rt.jar</systemPath>
</dependency>

import(Maven 2.0.9及以上): 导入依赖范围。该依赖范围不会对三种classpath产生实际的影响，稍后会介绍到。

3. 传递性依赖

下面我们看一个简单的项目，读者可从附件中下载源码

POM.xml配置如下：

Xml代码

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>com.mycompany.app</groupId>
<artifactId>my-app-simple</artifactId>
<version>0.0.1-SNAPSHOT</version>
<packaging>jar</packaging>
<name>my-app-simple</name>
<url>http://maven.apache.org</url>
<properties>
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
</properties>
<dependencies>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>3.8.1</version>
<scope>test</scope>
</dependency>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-core</artifactId>
<version>2.5.6</version>
</dependency>
</dependencies>
</project>

我们可以看到此项目引入依赖junit和spring-core，我们可以在Maven仓库中查找spring-core构件，如图：

点击POM我们会看到该文件包含了一个commons-logging依赖：

Xml代码

<dependency>
<groupId>commons-logging</groupId>
<artifactId>commons-logging</artifactId>
<version>1.1.1</version>
</dependency>

那么该依赖会传递到当前项目中，这就是依赖的传递性，打开项目查看Maven dependencies:

4. 可选依赖

有时候我们不想让依赖传递，那么可配置该依赖为可选依赖，将元素optional设置为true即可,例如：

Xml代码

<dependency>
<groupId>commons-logging</groupId>
<artifactId>commons-logging</artifactId>
<version>1.1.1</version>
<optional>true<optional>
</dependency>

那么依赖该项目的另以项目将不会得到此依赖的传递

5. 排除依赖

当我们引入第三方jar包的时候，难免会引入传递性依赖，有些时候这是好事，然而有些时候我们不需要其中的一些传递性依赖

比如上例中的项目，我们不想引入传递性依赖commons-logging，我们可以使用exclusions元素声明排除依赖，exclusions可以包含一个或者多个exclusion子元素，因此可以排除一个或者多个传递性依赖。需要注意的是，声明exclusions 的时候只需要groupId和artifactId，而不需要version元素，这是因为只需要groupId和artifactId就能唯一定位依赖图中的某个依赖。换句话说，Maven解析后的依赖中，不可能出现groupId和artifactId相同，但是version不同的两个依赖。

如下是一个排除依赖的例子：

Xml代码

<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-core</artifactId>
<version>2.5.6</version>
<exclusions>
<exclusion>
<groupId>commons-logging</groupId>
<artifactId>commons-logging</artifactId>
</exclusion>
</exclusions>
</dependency>

5. 依赖归类

如果我们项目中用到很多关于Spring Framework的依赖，它们分别是org.springframework:spring-core:2.5.6, org.springframework:spring-beans:2.5.6,org.springframework:spring- context:2.5.6,它们都是来自同一项目的不同模块。因此，所有这些依赖的版本都是相同的，而且可以预见，如果将来需要升级Spring Framework，这些依赖的版本会一起升级。因此，我们应该在一个唯一的地方定义版本，并且在dependency声明引用这一版本，这一在 Spring Framework升级的时候只需要修改一处即可。

Xml代码

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>com.mycompany.app</groupId>
<artifactId>my-app-simple</artifactId>
<version>0.0.1-SNAPSHOT</version>
<packaging>jar</packaging>
<name>my-app-simple</name>
<properties>
<springframework.version>2.5.6</springframework.version>
</properties>
<dependencies>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>3.8.1</version>
<scope>test</scope>
</dependency>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-core</artifactId>
<version>${springframework.version}</version>
</dependency>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-beans</artifactId>
<version>${springframework.version}</version>
</dependency>
</dependencies>
</project>