1. 安装jdk 略过  我的是这个版本Java(TM) SE Runtime Environment (build 1.6.0_38-b05) 
   • 如需ubuntu 安装配置jdk的教程，请点击  http://hi.baidu.com/xingfukaixin/item/fa85176ad76dba34ad3e8364
2. 安装Android-sdk  
   • http://developer.android.com/sdk/index.html
     
3. 到Maven的官方下载最新版本的Maven

• 下载地址 http://maven.apache.org/download.html
• 我下载的是 Maven 3.0.4
  
• 找个文件夹解压，并配置到系统的环境变量
  
  • /home/wuyexiong/Android/tool/maven/apache-maven-3.0.4/bin 配置到/etc/environment
  • ANDROID_HOME="/home/wuyexiong/Android/android-linux/adt-bundle-linux-x86_64/sdk"
    这个sdk  可以利用anroidmanager来下载 sdk
    
    

在父项目的 pluginManagement 中明确 使用 maven-site-plugin。而在每一个项目中都明确使用 maven-site-plugin

代码如下：父项目pom.xml：

 <build> 
<pluginManagement> 
<plugin> 
<groupId> org.apache.maven.plugins</groupId> 
<artifactId> maven-site-plugin</artifactId> 
<version> 2.0</version> 
</plugin> 
</plugins> 
</pluginManagement> 
<plugins> 
<plugin> 
<groupId> org.apache.maven.plugins</groupId> 
<artifactId> maven-site-plugin</artifactId> 
</plugin> 
</plugins> 
</build>

子项目pom.xml： 
<build> 
<plugins> 
<plugin> 
<groupId> org.apache.maven.plugins</groupId> 
<artifactId> maven-site-plugin</artifactId> 
</plugin> 
</plugins> 
</build>

创建两个项目

1.      cdai_codebase_parent：其他项目的Maven配置都继承这个项目中pom.xml的定义。

2.      cdai_codebase_ssh：一个SSH示例项目，继承parent项目中的配置。

首先看cdai_codebase_parent中pom.xml的内容：

通过将packaging属性定义为pom来说明当前pom.xml是用来被继承的。之后在parent的pom.xml中，我们可以定义一些统一的版本号（Spring等第三方包的），依赖项（所有项目都会用的JUnit），以及通用的打包配置等。

现在，我们就可以在cdai_codebase_ssh中，通过项目的相对路径引用这个parent的pom.xml文件了。

附：在父pom.xml中dependencyManagement中定义需要被继承的依赖，然后在子pom.xml中可以直接指定groupId和artifactId来引入，就不需要版本号了。

maven本质上是一个插件框架，它的所有工作都交给插件来做，每个插件可以有多个goal。

除了自带的插件之外还有很多比较成熟的第三方插件，我们也很容易上手进行简单的插件开发，下面一一介绍

1 自带插件

maven自带的核心插件为Build plugins和Reporting plugins。

mvn compile编译源码实际上就利用到了maven-compiler-plugin，其他phase也类似用到了相应的插件

关于maven自带的核心插件见：http://maven.apache.org/plugins/index.html

2 第三方插件

2.1 maven有很多成熟的第三方插件

如jetty 对于web开发使用jetty作为容器

native 编译c和c++代码

sql 执行sql脚本

其他更多见：http://maven.apache.org/plugins/index.html#Outside_The_Maven_Land

下面具体介绍下单元测试覆盖率插件cobertura、findbugs

2.2 maven2的cobertura插件

2.2.1 cobertura是一款用来计算java代码测试覆盖率的工具，基于jcoverage。能计算每个类、包、整个工程的行覆盖率和分支覆盖率以及代码复杂度(Cyclomatic complexity)并生成html或xml形式的报告，让用户很方便的查看代码的单元测试覆盖率情况。cobertura的原理是通过对class文件进行插桩然后计算。

2.2.2 maven2的cobertura插件介绍

插件地址为http://mojo.codehaus.org/cobertura-maven-plugin/index.html

a、首先在pom中添加配置如下

Xml代码  

1. <reporting>  
2.     <outputDirectory>target/site</outputDirectory>  
3.     <plugins>  
4.         <plugin>  
5.             <groupId>org.codehaus.mojo</groupId>  
6.             <artifactId>cobertura-maven-plugin</artifactId>  
7.         </plugin>  
8.     </plugins>    
9. </reporting>   

b、运行goal

到项目根目录下运行mvn cobertura:cobertura 将会插桩class文件、测试、生成覆盖率报告

cobertura支持的goal如下

• cobertura:check Check the Last Instrumentation Results.
• cobertura:clean Clean up rogue files that cobertura maven plugin is tracking.
• cobertura:dump-datafile Cobertura Datafile Dump Mojo.
• cobertura:instrument Instrument the compiled classes.
• cobertura:cobertura Instruments, Tests, and Generates a Cobertura Report.

c、在target\site\cobertura目录下生成报告文件，打开index.html可以查看具体报告

mvn cobertura:cobertura执行前会执行test phase，即执行单侧代码

2.3 maven2的findbugs插件

2.3.1 findbugs是静态检查java代码的工具，根据一些bugs的表达式检查代码中的bugs，可以自定义检查规则

2.3.2 maven2的findbugs插件介绍

插件地址为http://mojo.codehaus.org/findbugs-maven-plugin/index.html

a、首先在pom中添加配置如下

不同goal的配置略有不同，可自己调整，以下介绍的是mvn findbugs:findbugs的配置

Xml代码  

1. <reporting>  
2.     <plugins>  
3.       <plugin>  
4.         <groupId>org.codehaus.mojo</groupId>  
5.         <artifactId>findbugs-maven-plugin</artifactId>  
6.         <version>2.3.1</version>  
7.       </plugin>  
8.     </plugins>  
9. </reporting>  

b、运行goal

到项目根目录下运行mvn findbugs:findbugs将会开始检查，并生成bugs报告

findbugs支持的goal如下

Xml代码  

1. findbugs:check  
2.   Fail the build if there were any FindBugs violations in the source code. An  
3.   XML report is put out by default in the target directory with the errors. To  
4.   see more documentation about FindBugs' options, please see the FindBugs  
5.   Manual..  
6.   
7. findbugs:findbugs  
8.   Generates a FindBugs Report when the site plugin is run. The HTML report is  
9.   generated for site commands only.  
10.   
11. findbugs:gui  
12.   Launch the Findbugs GUI. It will use all the parameters in the POM fle.  
13.   
14. findbugs:help  
15.   Display help information on findbugs-maven-plugin.  
16.   Call  
17.     mvn findbugs:help -Ddetail=true -Dgoal=<goal-name>  
18.   to display parameter details.  

c、在target\site\findbugs目录下生成报告文件，打开index.html可以查看具体报告

mvn findbugs:findbugs绑定到了compile phase，即在编译时自动检查

http://qa.taobao.com/?p=4206

2.4 maven的source插件

2.4.1 source插件用来将工程打包成带源代码的jar包

2.4.2 maven2的source插件介绍

Xml代码  

1. <build>  
2.     <plugins>  
3.       <plugin>  
4.         <groupId>org.apache.maven.plugins</groupId>  
5.         <artifactId>maven-source-plugin</artifactId>  
6.         <version>2.1.2</version>  
7.         <executions>  
8.           <execution>  
9.             <id>attach-sources</id>  
10.             <phase>verify</phase>  
11.             <goals>  
12.               <goal>jar-no-fork</goal>  
13.             </goals>  
14.           </execution>  
15.         </executions>  
16.       </plugin>  
17.     </plugins>  
18. </build>  

直接运行mvn clean install会在target下打出两个包，带***-sources.jar的为源码包

2.5 maven的assembly插件

2.5.1 assembly插件可用来将工程依赖的jar包和工程都打成一个jar打包

2.5.2 maven2的assembly插件pom配置如下

Xml代码  

1. <build>  
2.     <plugins>         
3.       <plugin>  
4.         <artifactId>maven-assembly-plugin</artifactId>  
5.         <configuration>  
6.           <descriptorRefs>  
7.             <descriptorRef>jar-with-dependencies</descriptorRef>  
8.           </descriptorRefs>  
9.         </configuration>  
10.       </plugin>  
11.     </plugins>  
12. </build>  

直接运行mvn assembly:assembly会在target下出现***-with-dependencies.jar的jar包

2.6 插件开发

maven的插件开发相当简单，可以参考http://trinea.iteye.com/blog/1171957

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

• Clean Lifecycle 在进行真正的构建之前进行一些清理工作。
  
• Default Lifecycle 构建的核心部分，编译，测试，打包，部署等等。
  
• Site Lifecycle 生成项目报告，站点，发布站点。

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

知道了每套生命周期的大概用途和相互关系以后，来逐个详细看一下每套生命周期，Clean和Site相对比较简单，先解释一下。

每套生命周期都由一组阶段(Phase)组成，我们平时在命令行输入的命令总会对应于一个特定的阶段。比如，运行mvn clean ，这个的clean是Clean生命周期的一个阶段。有点绕？要知道有Clean生命周期，也有clean阶段。Clean生命周期一共包含了三个阶段：

• pre-clean  执行一些需要在clean之前完成的工作
• clean  移除所有上一次构建生成的文件
• post-clean  执行一些需要在clean之后立刻完成的工作

mvn clean 中的clean就是上面的clean，在一个生命周期中，运行某个阶段的时候，它之前的所有阶段都会被运行，也就是说，mvn clean 等同于 mvn pre-clean clean ，如果我们运行 mvn post-clean ，那么 pre-clean，clean 都会被运行。这是Maven很重要的一个规则，可以大大简化命令行的输入。

下面看一下Site生命周期的各个阶段：

• pre-site     执行一些需要在生成站点文档之前完成的工作
• site    生成项目的站点文档
• post-site     执行一些需要在生成站点文档之后完成的工作，并且为部署做准备
• site-deploy     将生成的站点文档部署到特定的服务器上

这里经常用到的是site阶段和site-deploy阶段，用以生成和发布Maven站点，这可是Maven相当强大的功能，Manager比较喜欢，文档及统计数据自动生成，很好看。

最后，来看一下Maven的最重要的Default生命周期，绝大部分工作都发生在这个生命周期中，这里，我只解释一些比较重要和常用的阶段：

• 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     将最终的包复制到远程的仓库，以让其它开发人员与项目共享。

基本上，根据名称我们就能猜出每个阶段的用途，关于其它阶段的解释，请参考http://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html

记住，运行任何一个阶段的时候，它前面的所有阶段都会被运行，这也就是为什么我们运行mvn install 的时候，代码会被编译，测试，打包。

此外，Maven的插件机制是完全依赖Maven的生命周期的，因此理解生命周期至关重要，在之后的文章里，我将会进一步解释Maven的插件机制。

首先介绍一下背景，公司访问外网有限制，项目组大部分人员不能访问maven的central repository，因此在局域网里找一台有外网权限的机器，搭建nexus私服，然后开发人员连到这台私服上 

环境是：nexus-2.1.1、maven-3.0.4、jdk-1.6.0_32 

一、用admin用户登陆nexus 

nexus的下载和安装都很简单，网上也有很多介绍，本文就不重复了。主要介绍一下安装之后的配置 

nexus的配置需要用admin角色完成，默认的密码是admin123，进入nexus首页之后，点击右上角，进行登录 



然后就可以在左边的菜单中进行配置了 



二、为nexus配置代理服务器 

由于这台机器需要通过代理才能访问外网，所以首先要配置代理服务器，在Administration-->Server中进行配置 



配置之后，nexus才能连上central repository，如果私服所在机器可以直接上外网，则可以省略这一步 

三、配置repository 

在Views/Repositories-->Repositories里进行配置 



nexus里可以配置3种类型的仓库，分别是proxy、hosted、group 

proxy是远程仓库的代理。比如说在nexus中配置了一个central repository的proxy，当用户向这个proxy请求一个artifact，这个proxy就会先在本地查找，如果找不到的话，就会从远程仓库 下载，然后返回给用户，相当于起到一个中转的作用 

hosted是宿主仓库，用户可以把自己的一些构件，deploy到hosted中，也可以手工上传构件到hosted里。比如说oracle的驱动程序，ojdbc6.jar，在central repository是获取不到的，就需要手工上传到hosted里 

group是仓库组，在maven里没有这个概念，是nexus特有的。目的是将上述多个仓库聚合，对用户暴露统一的地址，这样用户就不需要在pom中配置多个地址，只要统一配置group的地址就可以了 

nexus装好之后，已经初始化定义了一些repository，我们熟悉之后，就可以自行删除、新增、编辑 

右边那个Repository Path可以点击进去，看到仓库中artifact列表。不过要注意浏览器缓存。我今天就发现，明明构件已经更新了，在浏览器里却看不到，还以为是BUG，其实是被浏览器缓存了 

四、配置Central Repository的proxy 

最关键的一个配置，可能就是Central Repository的proxy配置，因为大部分的构件，都是要通过这个proxy得到的 



在安装完nexus之后，这个proxy是预置的，需要做的就是把Download Remote Indexes改为true，这样nexus才会从central repository下载索引，才能在nexus中使用artifact search的功能 

网络上有一些其他公开的maven仓库，可以用同样的办法，在nexus中设置proxy，但是并不是所有maven仓库，都提供了nexus index，这种情况下，就无法建立索引了 

五、配置hosted repository 

一般会配置3个hosted repository，分别是3rd party、Snapshots、Releases，分别用来保存第三方jar（典型的比如ojdbc6.jar），项目组内部的快照、项目组内部的发布版 



这里并没有什么特别的配置，只是Deployment Policy这个选项，一般Snapshots会配置成允许，而Releases和3rd party会设置为禁止 

六、配置group repository 

前面说过，group其实是一个虚拟的仓库，通过对实体仓库（proxy、hosted）进行聚合，对外暴露一个统一的地址 



这里要注意的是，放到左边的仓库，才是会被聚合的仓库。我昨天一直搞错了，把仓库都放到右边，结果group什么都没有聚合到，是一个空的仓库。。。 

七、配置用户密码 

在Security-->Users中配置，在deployment用户上点击右键，选择Set Password，然后设置一个密码，做这个操作是为了后面提交做准备 



八、在用户机器上配置settings.xml 

经过前面的7个步骤，nexus就配置好了，接下来需要在每个开发人员的开发机器上进行配置了 

配置文件在%USER_HOME%/.m2/settings.xml 

Xml代码  

1 <?xml version="1.0" encoding="UTF-8"?>  

2   

3 <settings xmlns="http://maven.apache.org/SETTINGS/1.0.0"   

4           xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"   

5           xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0 http://maven.apache.org/xsd/settings-1.0.0.xsd">  

6    

7   <servers>  

8     

9     <server>  

10         <id>nexus-snapshots</id>  

11         <username>deployment</username>  

12         <password>deployment</password>  

13     </server>  

14   

15   </servers>  

16     

17   <mirrors>  

18     

19     <mirror>  

20         <id>nexus</id>  

21         <name>internal nexus repository</name>  

22         <url>http://10.78.68.122:9090/nexus-2.1.1/content/groups/public/</url>  

23         <mirrorOf>central</mirrorOf>  

24     </mirror>  

25       

26   </mirrors>  

27     

28 </settings>  

这里只配置了2个元素<mirrors>和<servers> 

首先这里配置了一个id为nexus的镜像仓库，地址是前面配置的public group的URL，然后镜像目标是central 

maven里的超级pom，里面配置了这样一段： 

Xml代码  

29 <repositories>  

30     <repository>  

31       <id>central</id>  

32       <name>Central Repository</name>  

33       <url>http://repo.maven.apache.org/maven2</url>  

34       <layout>default</layout>  

35       <snapshots>  

36         <enabled>false</enabled>  

37       </snapshots>  

38     </repository>  

39   </repositories>  

40   

41   <pluginRepositories>  

42     <pluginRepository>  

43       <id>central</id>  

44       <name>Central Repository</name>  

45       <url>http://repo.maven.apache.org/maven2</url>  

46       <layout>default</layout>  

47       <snapshots>  

48         <enabled>false</enabled>  

49       </snapshots>  

50       <releases>  

51         <updatePolicy>never</updatePolicy>  

52       </releases>  

53     </pluginRepository>  

54   </pluginRepositories>  

因此，当本地的maven项目，找不到需要的构件（包括jar包和插件）的时候，默认会到central里获取 

所以我们刚刚配置的镜像仓库，id也是central，这样本地maven项目对central repository的请求，就会转到镜像仓库上，也就是我们设置的nexus私服上 

由于我们在项目的pom里，不会再配置其他的<repositories>和<pluginRepositories> 元素，所以只要配置一个central的mirror，就足以阻止所有的外网访问。如果pom中还配置了其他的外网仓库，比如jboss repository等，可以把<mirrorOf>改为* 

至于<servers>元素，是因为我们把项目内部的构件上传到nexus的仓库中时，nexus会进行权限控制，所以这里需要设置 权限相关的信息。注意这里的<id>nexus-snapshots</id>，和后面maven工程里的pom设置是一致的 

由于我们这里已经屏蔽了对外网仓库的请求，所以就不需要配置代理服务器了，如果需要配置代理服务器，可以用<proxies>元素 

九、配置maven项目的pom文件 

下面是简化后的pom文件： 

Xml代码  

55 <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"  

56     xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">  

57   

58     <modelVersion>4.0.0</modelVersion>  

59     <groupId>com.huawei.inoc.wfm.task</groupId>  

60     <artifactId>task-sla</artifactId>  

61     <version>0.0.1-SNAPSHOT</version>  

62     <name>task-sla</name>  

63   

64     <!-- 配置部署的远程仓库 -->  

65     <distributionManagement>  

66         <snapshotRepository>  

67             <id>nexus-snapshots</id>  

68             <name>nexus distribution snapshot repository</name>  

69             <url>http://10.78.68.122:9090/nexus-2.1.1/content/repositories/snapshots/</url>  

70         </snapshotRepository>  

71     </distributionManagement>  

72   

73 </project>  

这里配置了<distributionManagement>元素，其中的<id>nexus-snapshots</id>，与前面说的settings.xml中的<servers>元素中的配置必须一致 

配置这个的目的，是当执行maven deploy时，才知道要将生成的构件部署到哪个远程仓库上，注意这里的URL填的就不是public group的地址： 
http://10.78.68.122:9090/nexus-2.1.1/content/groups/public/ 

而是snapshots的地址： 
http://10.78.68.122:9090/nexus-2.1.1/content/repositories/snapshots/ 

但是在nexus中，snapshots也是聚合到public group里的，所以开发人员A提交到snapshots的构件，开发人员B也可以从public group里获取到 

十、eclipse中的设置 

经过前面的配置，已经可以通过命令行进行maven操作了。不过实际开发中，一般都是使用eclipse的m2e插件，所以还需要对eclipse进行一些额外的配置 

在Preferences-->Maven-->User Settings中，点击Update Settings，加载刚才我们对settings.xml的更改 



然后在Maven Repositories视图里，可以看到仓库的情况 



可以看到，从超级pom继承来的central被置灰了，不可用，后面的mirrored by nexus表示对该仓库的所有请求，都会转到镜像nexus中 

十一、nexus的目录结构 

nexus会安装在%USER_HOME%/sonatype-work/nexus下，有以下目录 



其中的storage目录，就是构件实际存放的地址了 

----------

在Maven的世界中，任何一个项目或者构件都必须有自己的版本。版本的值可能是1.0.0,1.3-alpha-4,2.0,2.1-SNAPSHOT或者2.1-20091214.221414-13。其中，1.0、1.3-alpha-4和2.0是稳定的发布版本，而2.1-SNAPSHOT和2.1-20091214.221414-13是不稳定的快照版本。

Maven为什么要区分发布版本和快照版本呢？简单的1.0.0、1.2、2.1等不就够了吗？为什么还要2.1-SNAPSHOT，甚至是长长的2.1-20091214.221414-13？试想一下这样的情况，小张在开发模块A的2.1版本，该版本还未正式发布，与模块A一同开发的还有模块B，它由小张的同事季MM开发，B的功能依赖于A。在开发的过程中，小张需要经常将自己最新的构建输出，交给季MM，供她开发和集成调试，问题是，这个工作如何进行呢？

如果不停更新版本2.1.1、2.1.2、2.1.3....呢？首先，小张和季MM两人都需要频繁地更改POM，如果有更多的模块依赖于模块A，就会涉及更多的POM更改；其次，大量的版本其实仅仅包含了微小的差异，这样也会造成为版本号的滥用。

Maven的快照版本机制就是为了解决上述问题。在该例中，小张只需要将模块A的版本设定为2.1-SNAPSHOT，然后发布到私服中，在发布的过程中，Maven会自动为构件打上时间戳。比如:2.1-20091214.221414-13就表示2009年12月14日 22点14分14秒的第13次快照。有了该时间戳，Maven就能随时找到仓库中该构件2.1-SNAPSHOT版本最新的文件。这时，季MM配置对于模块A的2.1-SNAPSHOT版本的依赖，当她构件模块B的时候，Maven会自动从仓库中检查模块A的2.1-SNAPSHOT的最新构件，当发现有更新时便进行下载。默认情况下，Maven每天检查一次更新(由仓库配置的updatePolicy控制)，用户也可以使用命令行-U参数强制让Maven检查更新，如：mvn clean install-U。

基于快照版本机制，小张在构建成功之后才能将构件部署至仓库，而季MM可以完全不用考虑模块A的构建，并且她能确保随时得到模块A的最新可用的快照构件，而这一切都不需要额外的手工操作。

----------

在很多情况下，默认的中央仓库无法满足项目的需求，可能项目需要的构件存在于另外一个远程仓库中，如:JBoss，Maven仓库。这时，可以在POM中配置该仓库，见代码请单：

Xml代码  

1. <project>  
2.   ...  
3.   <repositories>  
4.     <repository>  
5.       <id>jboss</id>  
6.       <name>JBoss Repository</name>  
7.       <url>http://repository.jboss.com/maven2/</url>  
8.       <releases>  
9.         <enabled>true</enabled>  
10.       </releases>  
11.     </repository>  
12.     <snapshots>  
13.       <enabled>false</enabled>  
14.     </snapshots>  
15.     <layout>default</layout>  
16.   </repositories>  
17.   ...  
18. </project>  

在repositories元素下，可以使用repository子元素声明一个或者多个远程仓库。该例中声明了一个id为jboss，名称为JBoss Repository的仓库。任何一个仓库声明的id必须是唯一的，尤其需要注意的是，maven自带的中央仓库使用的id为central，如果其他的仓库声明也使用该id，就会覆盖中央仓库的配置。该配置中的url值指向了仓库的地址，一般来说，该地址都基于http协议，maven用户都可以在浏览器中打开仓库地址浏览构件。

该例配置中的releases和snapshots元素比较重要，它们用来控制Maven对于发布版构件和快照版构件的下载。该例中releases的enabled值为true，表示开启JBoss仓库的发布版本下载支持，而snapshots的enabled值为false，表示关闭JBoss仓库的快照版本的下载支持。该例中的layout元素值default表示仓库的布局是Maven2及Maven3的默认布局，而不是Maven1的布局。

对于releases和snapshots来说，除了enabled，它们还包含另外两个子元素updatePolicy和checksumPolicy:

Xml代码  

1. <snapshots>  
2.   <enabled>true</enabled>  
3.   <updatePolicy>daily</updatePolicy>  
4.   <checksumPolicy>ignore</checksumPolicy>  
5. </snapshots>  

元素updatePolicy用来配置Maven从远程仓库检查更新的频率，默认的值是daily，表示Maven每天检查一次。其他可用的值包括：never---从不检查更新；always---每次构建都检查更新；interval:X---每隔X分钟检查一次更新(X为任意整数)。

元素checksumPolicy用来配置Maven检查检验和文件的策略。当构件被部署到Maven仓库中时，会同时部署对应的校验和文件。在下载构件的时候，Maven会验证校验和文件，如果校验和验证失败，怎么办？当checksumPolicy的值为默认的warn时，Maven会在执行构建时输出警告信息，其他可用的值包括：fail---Maven遇到校验和错误就让构建失败；ignore---使用Maven完全忽略校验和错误。

1.远程仓库的认证

大部分远程仓库无须认证就可以访问，但有时候出于安全方面的考虑，我们需要提认证信息才能访问一些远程仓库。例如，组织内部有一个Maven仓库服务器，该服务器为每个项目都提供独立的Maven仓库，为了防止非法的仓库访问，管理员为每个仓库提供了一组用户名级密码。这时，为了能让Maven访问仓库内容，就需要配置认证信息。

配置认证信息和配置仓库信息不同，仓库信息可以直接配置在POM文件中，但是认证信息必须配置在settings.xml文件中。这是因为POM往往是被提交到代码仓库中供所有成员访问的，而settings.xml一般只放在本机。因此，settings.xml中配置认证信息更为安全。假设需要为一个id为my-proj的仓库配置认证信息，编辑settings.xml文件见代码清单： 

Xml代码  

1. <settings>  
2.   ...  
3.   <servers>  
4.     <server>  
5.       <id>my-proj</id>  
6.       <username>repo-user</username>  
7.       <password>repo-pwd</password>  
8.     </server>  
9.   </servers>  
10.   ...  
11. </settings>  

Maven使用settings.xml文件中并不显而易见的servers元素及其server子元素配置仓库认证信息。上例中，仓库的认证用户名为repo-user，认证密码为repo-pwd。这里的关键是id元素，settings.xml中server元素的id必须与POM中需要认证的repository元素的id完全一致。换句话说，正是这个Id将认证信息与仓库配置联系在了一起。

2.部署至远程仓库

私服的一大作用是部署第三方构件，包括组织内部生成的构件以及一些无法从外部仓库直接获取的构件。无论是日常开发中生成的构件，还是正式版本发布的构件，都需要部署到仓库中，供其他团队成员使用。

Maven除了能对项目进行编译、测试、打包之外，还能将项目生成的构建部署到仓库中。首先，需要编辑项目的pom.xml文件。配置distributionManagement元素，见代码：

Xml代码  

1. <project>  
2.   ...  
3.   <destributionManagement>  
4.     <repository>  
5.       <id>proj-releases</id>  
6.       <name>Proj Release Repository</name>  
7.       <url>http://192.168.1.100/content/repositories/proj-releases</url>  
8.     </repository>  
9.     <snapshotRepository>  
10.       <id>proj-snapshots</id>  
11.       <name>Proj Snapshot Repository</name>  
12.       <url>http://192.168.1.100/content/repositories/proj-snapshots</url>  
13.     </snapshotRepository>  
14.   </destributionManagement>  
15.   ...  
16. </project>  

distributionManagement包含repository和snapshotRepository子元素，前者表示发布版本构件的仓库，后者表示快照版本的仓库。这两个元素下都需要配置id、name和url，id为该远程仓库的唯一标识，name是为了方便人阅读，关键的url表示该仓库的地址。

往远程仓库部署构件的时候，往往需要认证。就是需要在settings.xml中创建一个server元素，其id与仓库的id匹配，并配置正确的认证信息。不论远程仓库下载构件，还是部署构件至远程仓库，当需要认证的时候，配置的方式是一样的。配置正确后，在命令行运行mvn clean deploy，Maven就会将项目构建输出的构件部署到配置对应的远程仓库，如果项目当前的版本是快照版本，则部署到快照版本仓库地址，否则就部署到发布版本仓库地址。

在不用Maven的时候，比如说以前我们用Ant构建项目，在项目目录下，往往会看到一个名为/lib的子目录，那里存放着各类第三方依赖jar文件，如log4j.jar，junit.jar等等。每建立一个项目，你都需要建立这样的一个/lib目录，然后复制一对jar文件，这是很明显的重复。重复永远是噩梦的起点，多个项目不共用相同的jar文件，不仅会造成磁盘资源的浪费，也使得版本的一致性管理变得困难。此外，如果你使用版本管理工具，如SVN（你没有使用版本管理工具？马上试试SVN吧，它能帮你解决很多头疼的问题），你需要将大量的jar文件提交到代码库里，可是版本管理工具在处理二进制文件方面并不出色。

Maven仓库就是放置所有JAR文件（WAR，ZIP，POM等等）的地方，所有Maven项目可以从同一个Maven仓库中获取自己所需要的依赖JAR，这节省了磁盘资源。此外，由于Maven仓库中所有的JAR都有其自己的坐标，该坐标告诉Maven它的组ID，构件ID，版本，打包方式等等，因此Maven项目可以方便的进行依赖版本管理。你也不在需要提交JAR文件到SCM仓库中，你可以建立一个组织层次的Maven仓库，供所有成员使用。

简言之，Maven仓库能帮助我们管理构件（主要是JAR）。

本地仓库 vs. 远程仓库

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

比如说，你的项目配置了junit-3.8的依赖，在你运行mvn test 的时候，Maven需要使用junit-3.8的jar文件，它首先根据坐标查找本地仓库，如果找到，就直接使用。如果没有，Maven会检查可用的远程仓库配置，然后逐个尝试这些远程仓库去下载junit-3.8的jar文件，如果远程仓库存在该文件，Maven会将其下载到本地仓库中，继而使用。如果尝试过所有远程仓库之后，Maven还是没能够下载到该文件，它就会报错。

Maven缺省的本地仓库地址为${user.home}/.m2/repository 。也就是说，一个用户会对应的拥有一个本地仓库。

你也可以自定义本地仓库的位置，修改${user.home}/.m2/settings.xml ：

Xml代码

1. <settings>
2.   ...  
3. <localRepository>D:/java/repository</localRepository>
4.   ...  
5. </settings>

你还可以在运行时指定本地仓库位置：

mvn clean install -Dmaven.repo.local=/home/juven/myrepo/

还有一点需要理解的是，当我们运行install的时候，Maven实际上是将项目生成的构件安装到了本地仓库，也就是说，只有install了之后，其它项目才能使用此项目生成的构件。

了解了本地仓库，接着了解一下Maven缺省的远程仓库，即Maven中央仓库。

安装好Maven之后，我们可以建立一个简单的项目，配置一些简单的依赖，然后运行mvn clean install，项目就构建好了。我们没有手工的去下载任何jar文件，这一切都是因为Maven中央仓库的存在，当Maven在本地仓库找不到需要的jar文件时，它会查找远程仓库，而一个原始的Maven安装就自带了一个远程仓库——Maven中央仓库。

这个Maven中央仓库是在哪里定义的呢？在我的机器上，我安装了maven-2.0.10，我可以找到这个文件：${M2_HOME}/lib/maven-2.0.10-uber.jar ，打开该文件，能找到超级POM：/org/apache/maven/project/pom-4.0.0.xml ，它是所有Maven POM的父POM，所有Maven项目继承该配置，你可以在这个POM中发现如下配置：

Xml代码

1. <repositories>
2. <repository>
3. <id>central</id>
4. <name>Maven Repository Switchboard</name>
5. <layout>default</layout>
6. <url>http://repo1.maven.org/maven2</url>
7. <snapshots>
8. <enabled>false</enabled>
9. </snapshots>
10. </repository>
11. </repositories>

关于远程仓库的配置，下面的小节我会详细解释，这里我们只要知道，中央仓库的id为central，远程url地址为http://repo1.maven.org/maven2，它关闭了snapshot版本构件下载的支持。

在POM中配置远程仓库

前面我们看到超级POM配置了ID为central的远程仓库，我们可以在POM中配置其它的远程仓库。这样做的原因有很多，比如你有一个局域网的远程仓库，使用该仓库能大大提高下载速度，继而提高构建速度，也有可能你依赖的一个jar在central中找不到，它只存在于某个特定的公共仓库，这样你也不得不添加那个远程仓库的配置。

这里我配置一个远程仓库指向中央仓库的中国镜像：

Xml代码

1. <project>
2. ...  
3. <repositories>
4. <repository>
5. <id>maven-net-cn</id>
6. <name>Maven China Mirror</name>
7. <url>http://maven.net.cn/content/groups/public/</url>
8. <releases>
9. <enabled>true</enabled>
10. </releases>
11. <snapshots>
12. <enabled>false</enabled>
13. </snapshots>
14. </repository>
15. </repositories>
16. <pluginRepositories>
17. <pluginRepository>
18. <id>maven-net-cn</id>
19. <name>Maven China Mirror</name>
20. <url>http://maven.net.cn/content/groups/public/</url>
21. <releases>
22. <enabled>true</enabled>
23. </releases>
24. <snapshots>
25. <enabled>false</enabled>
26. </snapshots>
27. </pluginRepository>
28. </pluginRepositories>
29. ...  
30. </project>

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

关于<repositories>的更详细的配置及相关解释，请参考：http://www.sonatype.com/books/maven-book/reference_zh/apas02s08.html。

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

在settings.xml中配置远程仓库

我们知道了如何在POM中配置远程仓库，但考虑这样的情况：在一个公司内部，同时进行这3个项目，而且以后随着这几个项目的结束，越来越多的项目会开始；同时，公司内部建立一个Maven仓库。我们统一为所有这些项目配置该仓库，于是不得不为每个项目提供同样的配置。问题出现了，这是重复 ！

其实我们可以做到只配置一次，在哪里配置呢？就是settings.xml。

不过事情没有那么简单，不是简单的将POM中的<repositories>及<pluginRepositories>元素复制到settings.xml中就可以，setting.xml不直接支持 这两个元素。但我们还是有一个并不复杂的解决方案，就是利用profile，如下：

Xml代码

1. <settings>
2.   ...  
3. <profiles>
4. <profile>
5. <id>dev</id>
6. <!-- repositories and pluginRepositories here-->
7. </profile>
8. </profiles>
9. <activeProfiles>
10. <activeProfile>dev</activeProfile>
11. </activeProfiles>
12.   ...  
13. </settings>

这里我们定义一个id为dev的profile，将所有repositories以及pluginRepositories元素放到这个profile中，然后，使用<activeProfiles>元素自动激活该profile。这样，你就不用再为每个POM重复配置仓库。

使用profile为settings.xml添加仓库提供了一种用户全局范围的仓库配置。

镜像

如果你的地理位置附近有一个速度更快的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>

关于更加高级的镜像配置，可以参考：http://maven.apache.org/guides/mini/guide-mirror-settings.html。

分发构件至远程仓库

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

我们需要配置POM的distributionManagement来指定Maven分发构件的位置，如下：

Xml代码

1. <project>
2.   ...    
3. <distributionManagement>
4. <repository>
5. <id>nexus-releases</id>
6. <name>Nexus Release Repository</name>
7. <url>http://127.0.0.1:8080/nexus/content/repositories/releases/</url>
8. </repository>
9. <snapshotRepository>
10. <id>nexus-snapshots</id>
11. <name>Nexus Snapshot Repository</name>
12. <url>http://127.0.0.1:8080/nexus/content/repositories/snapshots/</url>
13. </snapshotRepository>
14. </distributionManagement>
15.   ...    
16. </project>

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

一般来说，分发构件到远程仓库需要认证，如果你没有配置任何认证信息，你往往会得到401错误。这个时候，如下在settings.xml中配置认证信息：

Xml代码

1. <settings>
2.   ...    
3. <servers>
4. <server>
5. <id>nexus-releases</id>
6. <username>admin</username>
7. <password>admin123</password>
8. </server>
9. <server>
10. <id>nexus-snapshots</id>
11. <username>admin</username>
12. <password>admin123</password>
13. </server>
14. </servers>
15.   ...    
16. </settings>

需要注意的是，settings.xml中server元素下id的值必须与POM中repository或snapshotRepository下id的值完全一致。将认证信息放到settings下而非POM中，是因为POM往往是它人可见的，而settings.xml是本地的。

小结

本文介绍了Maven仓库，它是什么？本地仓库，远程仓库，中央仓库具体是指什么？并介绍了如何在POM中配置项目层次的仓库，在settings中配置用户层次的仓库，以及mirror。本文还介绍了如何安装构件到本地仓库，如何分发构件至仓库。

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

     (2).artifactId,该元素定义实际项目中的一个maven项目(模块),推荐的做法是使用实际项目名称作为artifactId前缀，这样做的好处是方便寻找实际构件。在默认情况下，maven生成的构件，其文件名会以artifactId作为开头，如:helloworld-1-0.0.1-SNAPSHOT.jar，使用实际项目名称作为前缀之后，就能方便从一个lib文件夹中找到某个项目的一组构件。。

     (3).version,该元素定义maven项目当前所处的版本，如：helloworld-1-0.0.1-SNAPSHOT.jar的版本是0.0.1。需要注意的是，maven定义了一套完整的版本规范，以及快照(SNAPSHOT)的概念。

     (4).packaging, 定义了maven项目的打包方式。默认值为jar，可取值：ejb / ejb3 /jar / par / rar / war。

     (5).classifier,该元素用来帮助定义构建输出的一些附属构件。附属构件与主构件对应，如上例中的主构件是: nexus-indexer-2.0.0.jar，该项目可能还会通过使用一些插件生成如：helloworld-1-0.0.1-SNAPSHOT-javadoc.jar、helloworld-1-0.0.1-SNAPSHOT-sources.jar这样一些附属构件，其包含了java文档和源代码。这时候，javadoc和sources就是这两个附属构件的classifier。这样，附属构件也就拥有了自己唯一的坐标。

 项目构件的文件名是与坐标相对应, 规则为: artifactId-version[-classifier].packaging，[-classifier]为可选。

3.8 小结 

Hello World项目中有一些Maven的约定：在项目的根目录中放置pom.xml，在src/main/java目录中放置项目的主代码，在src/test/java中放置项目的测试代码。之所以一步一步地展示这些步骤，是为了能让可能是Maven初学者的你得到最实际的感受。我们称这些基本的目录结构和pom.xml文件内容称为项目的骨架，当第一次创建项目骨架的时候，你还会饶有兴趣地去体会这些默认约定背后的思想，第二次，第三次，你也许还会满意自己的熟练程度，但第四、第五次做同样的事情，你可能就会恼火了。为此Maven提供了Archetype以帮助我们快速勾勒出项目骨架。

还是以Hello World为例，我们使用maven archetype来创建该项目的骨架，离开当前的Maven项目目录。

如果是Maven 3，简单地运行：

mvn archetype:generate 

如果是Maven 2，最好运行如下命令：

mvn org.apache.maven.plugins:mavenarchetype
plugin:2.0alpha5:generate  

很多资料会让你直接使用更为简单的 mvn archetype:generate 命令，但在Maven 2中这是不安全的，因为该命令没有指定Archetype插件的版本，于是Maven会自动去下载最新的版本，进而可能得到不稳定的SNAPSHOT版本，导致运行失败。然而在Maven 3中，即使用户没有指定版本，Maven也只会解析最新的稳定版本，因此这是安全的。具体内容见7.7节。

我们实际上是在运行插件mavenarchetypeplugin，注意冒号的分隔，其格式为 groupId:artifactId:version:goal，org.apache.maven.plugins 是maven官方插件的groupId，mavenarchetypeplugin 是Archetype插件的artifactId，2.0alpha5 是目前该插件最新的稳定版，generate是要使用的插件目标。

紧接着会看到一段长长的输出，有很多可用的Archetype供选择，包括著名的Appfuse项目的Archetype、JPA项目的Archetype等。每一个Archetype前面都会对应有一个编号，同时命令行会提示一个默认的编号，其对应的Archetype为mavenarchetypequickstart，直接回车以选择该Archetype，紧接着Maven会提示输入要创建项目的groupId、artifactId、version以及包名package。如下输入并确认：

Define value for groupId: : com.juvenxu.mvnbook  
Define value for artifactId: : helloworld  
Define value for version:  1.0SNAPSHOT: :  
Define value for package:  com.juvenxu.mvnbook: : 
com.juvenxu.mvnbook.helloworld  
Confirm properties configuration:  
groupId: com.juvenxu.mvnbook  
artifactId: helloworld  
version: 1.0SNAPSHOT  
package: com.juvenxu.mvnbook.helloworld 
Y: : YArchetype

----------

将项目进行编译，测试之后，下一个重要步骤就是打包。pom.xml中如果没有指定打包类型，默认打包类型为：jar。我们可以简单地执行命令打包： mvn clean pachage。

类似地，maven会在打包之前执行编译，测试等操作。如以打jar包为例，jar:jar任务负责打包，实际上就是jar插件的jar目标将项目主代码打包成一个名为xxxxxx-1.0-SNAPSHOT.jar的文件。该文件也位于target/输出目录中，它是根据artifact-version.jar的规则进行命名的，如有需要，还可以使用finalName来自定义该文件的名称，这里暂且不展开，后面会详细解释。

在打包之后，又执行了安装任务install:install。从输出可以看到任务将项目输出的jar安装到了maven本地仓库中，可以打开相应的文件夹看到项目的pom和jar。之前我们说只有构件被下载到本地仓库后，才能由所有Maven项目使用，这里同样的道理，只有将自己编写的项目安装到本地仓库之后，其他maven项目才能使用它。

我们已经体验了maven最主要的命令：mvn clean compile，mvn clean test，mvn clean package，mvn clean install。执行test之前是会先执行compile的，执行package之前是会先执行test的，而类似地，install之前会执行package。可以在任何一个maven项目中执行这些命令。

默认打包是生成jar的，如果我的项目还有main方法的，我想打包成可执行的jar包，为了生成可执行的jar文件，需要借助maven-shade-plugin,配置该插件如下：

Xml代码  

1. <plugin>  
2.     <groupId>org.apache.maven.plugins</groupId>  
3.     <artifactId>maven-shade-plugin</artifactId>  
4.     <version>1.2.1</version>  
5.     <executions>  
6.         <execution>  
7.             <phase>package</phase>  
8.             <goals>  
9.                 <goal>shade</goal>  
10.             </goals>  
11.             <configuration>  
12.                 <transformers>  
13.                     <transformer implementation="org.apache.maven.plugins.shade.resource.ManifestResourceTransformer">  
14.                         <mainClass>com.juvenxu.mvnbook.helloworld.HelloWorld</mainClass>  
15.                     </transformer>  
16.                 </transformers>  
17.             </configuration>  
18.         </execution>  
19.     </executions>  
20. </plugin>  

默认打包生成jar是不能够直接运行的，因为带有main方法的类信息不会添加到manifest中(打开jar文件中的META-INF/MANIFEST.MF文件，将无法看到Main-Class一行)。

plugin元素在POM中的相对位置应该在<project><build><plugins>下面。我们配置了mainClass为com.juvenxu.mvnbook.helloworld.HelloWorld，项目在打包时会将该信息放到MANIFEST中。现在执行mvn clean install，待构建完成之后打开target/目录，可以看到hello-world-1.0-SNAPSHOT.jar和original-hello-world-1.0-SNAPSHOT.jar，前者是带有Main-Class信息的可执行jar，后者是原始的jar，打开hello-world-1.0-SNAPSHOT.jar的META-INF/MANIFEST.MF，可以看到它包含这样一行信息：

Main-Class:com.juvenxu.mvnbook.helloworld.HelloWorld

现在，在项目根目录中执行该jar文件：

D:\code\hello-world > java-jar target\hello-world-1.0-SNAPSHOT.jar，可以得到正确的输出了。

1：创建名为：helloword的maven项目

2:/helloword/src/main/java下建立package包hello，在包下建类SayHello

package hello;

public class SayHello {

    public String sayhello() {
        System.out.println("hello............is anybody here...");
        return "dddddddddddddddddddddddddd";
    }

    public static void main(String[] arg) {
        System.out.println(new SayHello().sayhello());
    }
}
3：/helloword/src/test/java下建立test包，在test包下建HelloWordTest类

package test;

import hello.SayHello;
import junit.framework.Assert;
import junit.framework.TestCase;

public class HelloWordTest extends TestCase {

    public HelloWordTest(String name) {
        super(name);
    }
      protected void setUp() {                                         //进行初始化的任务
            
          }
    /**
     * @param args
     */
    public void testSayHello()
    {
        SayHello s = new SayHello();
        String r = s.sayhello();
        Assert.assertEquals("dddddddddddddddddddddddddd", r);
    }
}

4：pom.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.houwen.test</groupId>
  <artifactId>helloword</artifactId>
  <version>0.0.1-SNAPSHOT</version>
  <name>Maven Helloword</name>

<!--junit依赖是为tset准备，配置后，记得install,把依赖包嵌入resourse内，-->
   <dependencies>
    <dependency>
      <groupId>junit</groupId>
      <artifactId>junit</artifactId>
      <version>3.8.1</version>
      <scope>test</scope>
    </dependency>
    </dependencies>
        <build>

<!--maven-shade-plugin

而要得到一个可以直接在命令行通过java命令运行的JAR文件，还要满足两个条件：
　　JAR包中的/META-INF/MANIFEST.MF元数据文件必须包含Main-Class信息。

Maven有好几个插件能帮助用户完成上述任务，不过用起来最方便的还是maven-shade-plugin，它可以让用户配置Main-Class的值，然后在打包的时候将值填入/META-INF/MANIFEST.MF文件。关于项目的依赖，它很聪明地将依赖JAR文件全部解压后，再将得到的.class文件连同当前项目的.class文件一起合并到最终的CLI包中，这样，在执行CLI JAR文件的时候，所有需要的类就都在Classpath中了。下面是一个配置样例：

-->
        <plugins>
        <plugin>
           <groupId>org.apache.maven.plugins</groupId>
           <artifactId>maven-shade-plugin</artifactId>
           <version>1.2.1</version>
           <executions>
                      <execution>
               <phase>package</phase>
               <goals>
                     <goal>shade</goal>
               </goals>
               <configuration>
                     <transformers>
                       <transformer implementation="org.apache.maven.plugins.shade.resource.ManifestResourceTransformer">
                        <mainClass>hello.SayHello</mainClass>
                      </transformer>
                     </transformers>
               </configuration>
                </execution>
           </executions>
        </plugin>
        </plugins>
    </build>
</project>

4.1上述例子中的，运行maven package后

我的Main-Class是hello.SayHello，构建完成后，对应于一个常规的helloword-0.0.1-SNAPSHOT.jar文件，我还得到了一个original-helloword-0.0.1-SNAPSHOT.jar文件。最后，我可以通过helloword-0.0.1-SNAPSHOT.jar命令运行程序。

4.2之后再运行maven install,把生成的jar打入到本地的maven仓库，可以在C:\Documents and Settings\hcen\.m2\repository\com\houwen\test\helloword\0.0.1-SNAPSHOT

找到helloword-0.0.1-SNAPSHOT.jar

5.最后，我可以通过java -jar  (jar包路径)/helloword-0.0.1-SNAPSHOT.jar命令运行程序。

用Maven生成一个包孕所有依赖jar包的可执行的jar包

create an executable jar with dependencies using Maven:

using plugin - onejar-maven-plugin. Example below (mvn package build jar):

<plugin>
     <groupId>org.dstovall</groupId>
     <artifactId>onejar-maven-plugin</artifactId>
     <version>1.3.0</version>
     <executions>
           <execution>
              <configuration>
                  <mainClass>com.company.MainClass</mainClass>
              </configuration>
              <goals>
                  <goal>one-jar</goal>
              </goals>
           </execution>
     </executions>
</plugin>

You need to add repository for that plugin:

<pluginRepositories>
     <pluginRepository>
           <id>onejar-maven-plugin.googlecode.com</id>
           <url>http://onejar-maven-plugin.googlecode.com/svn/mavenrepo</url>
     </pluginRepository>
</pluginRepositories>

就像Make的Makefile、Ant的build.xml一样，Maven项目的核心是pom.xml。POM（Project Object Model，项目对象模型）定义了项目的基本信息，用于描述项目如何构建，声明项目依赖，等等。现在先为Hello World项目编写一个最简单的pom.xml。

首先创建一个名为helloworld的文件夹，打开该文件夹，新建一个名为pom.xml的文件，输入其内容，如代码清单3-1所示。

代码清单3-1 Hello World的POM

<?xml version="1.0" encoding="UTF-8"?> 
<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.juvenxu.mvnbook</groupId> 
<artifactId>helloworld</artifactId> 
<version>1.0SNAPSHOT</version> 
<name>Maven Hello World Project</name> 
</project> 

代码的第一行是XML头，指定了该xml文档的版本和编码方式。紧接着是project元素，project是所有pom.xml的根元素，它还声明了一些POM相关的命名空间及xsd元素，虽然这些属性不是必须的，但使用这些属性能够让第三方工具（如IDE中的XML编辑器）帮助我们快速编辑POM。

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

这段代码中最重要的是包含groupId、artifactId和version的三行。这三个元素定义了一个项目基本的坐标，在Maven的世界，任何的jar、pom或者war都是以基于这些基本的坐标进行区分的。

groupId定义了项目属于哪个组，这个组往往和项目所在的组织或公司存在关联。譬如在googlecode上建立了一个名为myapp的项目，那么groupId就应该是com.googlecode.myapp，如果你的公司是mycom，有一个项目为myapp，那么groupId就应该是com.mycom.myapp。本书中所有的代码都基于groupId com.juvenxu.mvnbook。

artifactId定义了当前Maven项目在组中唯一的ID，我们为这个Hello World项目定义artifactId为helloworld，本书其他章节代码会分配其他的artifactId。而在前面的groupId为com.googlecode.myapp的例子中，你可能会为不同的子项目（模块）分配artifactId，如myapputil、myappdomain、myappweb等。

顾名思义，version指定了Hello World项目当前的版本——1.0SNAPSHOT。SNAPSHOT意为快照，说明该项目还处于开发中，是不稳定的版本。随着项目的发展，version会不断更新，如升级为1.0、1.1SNAPSHOT、1.1、2.0等。6.5节会详细介绍SNAPSHOT，第13章会介绍如何使用Maven管理项目版本的升级发布。

最后一个name元素声明了一个对于用户更为友好的项目名称，虽然这不是必须的，但还是推荐为每个POM声明name，以方便信息交流。

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