Maven问题总结及笔记汇总

1. 常用命令备忘

打包 package 或者 安装 install 时，跳过失败的单元测试类UT的命令行：

mvn install -Dmaven.test.skip=true

将下载或者从其他路径得到的，但是在maven repository找不到artifact Id信息的jar包安装到本地仓库的命令，然后就可以通过使用maven的pom文件来管理，而不是最传统的配置classpath的方法：
mvn install:install-file -Dfile=neuroph-2.6.jar -DgroupId=org.neuroph -DartifactId=neuroph -Dversion=2.6 -Dpackaging=jar
注意需要在 jar 包的目录下面执行这个命令。

2. maven-assembly-plugin

在一个Linux环境下使用maven-assembly-plugin插件，前期使用得很正常，后来报错：

Failed to execute goal org.apache.maven.plugins:maven-assembly-plugin:2.6:single (make-assembly) on project suite-demo-config-web: Execution make-assembly of goal org.apache.maven.plugins:maven-assembly-plugin:2.6:single failed: user id '3518522' is too big ( > 2097151 ). -> [Help 1]

经过排查，发现问题是版本导致的，将目前使用的版本由2.6降到2.4，解决问题，深层原因暂时未知。
参考链接：https://stackoverflow.com/questions/33943565/error-with-maven-build-with-assembly-plugin

3.wagon-maven-plugin

在pom.xml文件里面的<build>里面配置：

<extensions>
    <extension>
        <groupId>org.apache.maven.wagon</groupId>
        <artifactId>wagon-ssh</artifactId>
        <version>2.8</version>
    </extension>
</extensions>
<plugin>
    <groupId>org.codehaus.mojo</groupId>
    <artifactId>wagon-maven-plugin</artifactId>
    <version>1.0</version>
    <configuration>
        <serverId>15.119.81.111</serverId>
        <fromFile>target/extractor-alm.jar</fromFile>
        <url>
            scp://[email protected]/home/hpba/HPBA-340-340-master-redhat-x64/ContentPacks/ALM/EXTRACTOR/extractor-alm/
        </url>
    </configuration>
</plugin>

同时在maven的setting.xml文件里面配置server信息（用户名和密码）
实现jar/war包自动上传到server，部署。

4. maven classifier 的作用

一般情况下，在 pom 文件引入某个 dependency 时指定<groupId>、<artifactId>、<version>即可，但是在使用json-lib，mvn.repository.com查找它的dependency时结果如下：

<dependency>    
    <groupId>net.sf.json-lib</groupId>   
    <artifactId>json-lib</artifactId>    
    <version>2.4</version>    
</dependency>

然而import时提示无法找到这个jar。
原因是：json-lib提供两个jdk版本的实现， json-lib-2.1-jdk13.jar和json-lib-2.1-jdk15.jar。
解决办法，在dependency 标签里面添加classifier：

<dependency>    
    <groupId>net.sf.json-lib</groupId>   
    <artifactId>json-lib</artifactId>    
    <version>2.4</version>    
    <classifier>jdk15</classifier>  
</dependency>

即添加json-lib-2.4-jdk15.jar。classifier用于区分名字相同但内容不同的POM。例如：jdk15和jdk14指明目标版本；sources和javadoc指明部署的是源码还是文档。

5.docker-maven-plugin

在使用spotify的docker-maven-plugin遇到的一个问题。
Linux环境下配置好docker-maven-plugin插件的maven pom文件，前期使用完全没有问题，后来执行mvn clean install遇到报错：

Retrying request to {}->unix://localhost:80
...
Failed to execute goal com.spotify:docker-maven-plugin:0.4.13:build (build-image) on project demo-suite-data-image: Exception caught: java.util.concurrent.ExecutionException: com.spotify.docker.client.shaded.javax.ws.rs.ProcessingException: java.io.IOException: No such file or directory –

初始时，把报错信息的焦点定位于ProcessingException以及No such file or directory，当然google不懂任何有用的信息。
换个思路，google Retrying request to {}->unix://localhost:80。
找到参考：https://github.com/spotify/docker-maven-plugin/issues/105
总结起来就是，你现在的Linux坏境docker已经出问题，maven插件需要借助于docker环境（如docker daemon等） ；docker verion或者docker info提示有错，maven当然会执行失败。

6.maven-assembly-plugin

使用maven的assembly插件时遇到的一个问题。
需求场景是：把web工程mvn clean install生成的war包放置到下载之后的JBoss压缩包解压缩之后的文件夹deployment/standalone下面，替换里面的已有war包，重新打包成tar.gz格式的压缩包供后面的dockerfile使用。pom.xml及assembly.xml文件一切配置就绪。
前期使用也是正常，几次之后出问题，报错：

[WARNING] Entry: hpas-7.4.3/bundles/system/layers/base/javax/servlet/api/v25/jboss-servlet-api_2.5_spec-1.0.1.Final.jar longer than 100 characters.

网上有很多类似的故障如：http://stackoverflow.com/questions/9416511/tycho-shots-a-warning-when-my-entry-is-longer-than-100-chars
各种google之后，解决方法有两类：
1.不用这个assembly插件，换一个更强大的tycho-p2-director-plugin[http://git.eclipse.org/c/tycho/org.eclipse.tycho.git/] ,但是需要重新学习了解的成本。
2.更新maven的插件版本，从现有的2.6之后升级到3.0.0，但是：

貌似很多时候，maven的插件报错不影响其功能使用。
但是，这都不是完美的解决方案。
终于找到一个更靠谱的解决方法：
https://github.com/downgoon/memcloud/issues/4
在< plugin>——<execution>——<configuration>下面配置

<tarLongFileMode>gnu</tarLongFileMode>

7. Eclipse导入maven项目报错：could not read pom.xml

如图，IDE是Eclipse，导入GitHub上面git clone的maven项目时，报错：

参考：http://blog.csdn.net/t123012009065/article/details/17333773
意思是pom.xml有不能解析的配置项，把不能解析的配置修改过来即可。
与其他pom文件对比，发现多了这一行：

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

去掉就行。wait but why？git clone的maven项目，怎么会有这种问题呢？还是一个高star的项目。

8. Eclipse解析pom.xml文件报错

报错信息如此：
Plugin execution not covered by lifecycle configuration with：org.jvnet.maven-antrun-extended-plugin:maven-antrun-extended-plugin:1.43:run(execution: unpack, phase: compile)

具体是配置和GWT相关。
参考：
http://stackoverflow.com/questions/14886380/generated-project-with-gwt-maven-plugin-eclipse
http://stackoverflow.com/questions/8523737/why-am-i-receiving-a-plugin-execution-not-covered-by-lifecycle-configuration-wi
如图所示大致解决方法：

1. 第一种会改变pom.xml文件，生产代码，不推荐提交更改；
2. 更改自己本地开发坏境的配置，即将修改置于settings directory，建议。

9. maven-resources-plugin的使用

直入主题：

<build>
	<plugins>
	    <plugin>
	        <artifactId>maven-resources-plugin</artifactId>
	        <version>3.0.1</version>
	        <executions>
	            <execution>
	                <id>copy-resources</id>
	                <phase>package</phase>
	                <goals>
	                    <goal>copy-resources</goal>
	                </goals>
	                <configuration>
	                    <outputDirectory>docker</outputDirectory>
	                    <outputDirectory>kubernetes</outputDirectory>
	                    <resources>
	                        <resource>
	                            <directory>target</directory>
	                            <includes>
	                                <include>*.jar</include>
	                            </includes>
	                        </resource>
	                    </resources>
	                </configuration>
	            </execution>
	        </executions>
	    </plugin>
	</plugins>
</build>

如上配置，只有最后一个outputDirectory是有效的，即只把target下面的jar文件copy到kubernetes，并没有copy到上一个配置的outputDirectory，即docker。

那配置两个maven-resources-plugin？如下所示：

<plugin>
    <artifactId>maven-resources-plugin</artifactId>
    <version>3.0.1</version>
    <executions>
        <execution>
            <id>copy-resources</id>
            <phase>package</phase>
            <goals>
                <goal>copy-resources</goal>
            </goals>
            <configuration>
                <outputDirectory>kubernetes</outputDirectory>
                <resources>
                    <resource>
                        <directory>target</directory>
                        <includes>
                            <include>*.jar</include>
                        </includes>
                    </resource>
                </resources>
            </configuration>
        </execution>
    </executions>
</plugin>

<plugin>
    <artifactId>maven-resources-plugin</artifactId>
    <version>3.0.1</version>
    <executions>
        <execution>
            <id>copy-resources</id>
            <phase>package</phase>
            <goals>
                <goal>copy-resources</goal>
            </goals>
            <configuration>
                <outputDirectory>docker</outputDirectory>
                <resources>
                    <resource>
                        <directory>target</directory>
                        <includes>
                            <include>*.jar</include>
                        </includes>
                    </resource>
                </resources>
            </configuration>
        </execution>
    </executions>
</plugin>

也是只有下面一个配置项生效。

10.关于maven scope

1.Compile（编译）
compile，默认值。编译范围依赖在所有的classpath中可用，同时它们也会被打包。依赖的传递性只在compile范围进行。
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（导入）：
只使用在dependencyManagement中，表示从其它的pom中导入dependency的配置。

下面重点讲解compile 和 provided区别

对于scope=compile的情况（默认scope)，也就是说这个项目在编译，测试，运行阶段都需要这个artifact对应的jar包在classpath中。
而对于scope=provided的情况，则可以认为这个provided是目标容器已经provide这个artifact。换句话说，它只影响到编译，测试阶段。在编译测试阶段，需要这个artifact对应的jar包在classpath中，而在运行阶段，假定目标的容器（如tomcat、jboss）已经提供这个jar包，所以无需这个artifact对应的jar包。
实际插件的行为：
用maven install生成最终的构件包demo.war后，在其下的WEB-INF/lib中，会包含被标注为scope=compile的构件的jar包，而不会包含被标注为scope=provided的构件的jar包。这也避免此类构件当部署到目标容器后产生包依赖冲突。

11. Maven 环境变量

在将近三年的java开发生涯，maven环境变量的配置进行不少次，有说M2_HOME，有说MAVEN_HOME，但是一直搞不清楚两者有什么区别？知道最近在搭建.NET开发环境的时候，安装一个.NET 工程转maven工程的插件NPanday时才知道，两者并存的情况下，M2_HOME的优先级更高。

两者并存时输入命令：mvn -v：

12. mvn clean 报错 Unknown host

执行无数次的mvn clean竟然报错：
Plugin org.apache.maven.plugins:maven-clean-plugin:2.5 or one of its dependencies could not be resolved: Failed to read artifact descriptor for org.apache.maven.plugins:maven-clean-plugin:jar
:2.5: Could not transfer artifact org.apache.maven.plugins:maven-clean-plugin:pom:2.5 from/to nexus (http://maven.release.johnnycorp.com/nexus/content/groups/public): maven.dev.sh.johnnycorp.com: Unknown host maven.dev.sh.johnnycorp.com。hostname做了替换！
命令行：ping maven.dev.sh.johnnycorp.com报错：
Ping 请求找不到主机 maven.dev.sh.johnnycorp.com。请检查该名称，然后重试。
但是使用右侧的maven projects面板，lifecycle 选择clean，双击，则没有问题！！！哪里来的这个莫名其妙的hostname？？只可能是maven 的settings.xml，在内网的 confluence wiki 搜索到另外一个settings.xml配置文件；
对比一下现在使用的，没有什么差别！！但是替换之后就没有问题！！

13. maven解析依赖出错

问题背景：公司配置的Win 10系统，由于一些权限上的问题，会找IT帮忙解决，于是在本地磁盘留下用户信息：

如图，加码的是我的个人用户名信息，下面的lpxie是IT人员在操作我的电脑时留下的用户信息。
现在想要在本地安装jar包，用
mvn install:install-file -Dfile=jbarcode-0.2.8.jar -DgroupId=org.jbarcode -DartifactId=jbarcode -Dversion=0.2.8 -Dpackaging=jar
命令没有任何问题，打印输出： BUILD SUCCESS。
但是IDEA还是出现解析依赖出错的红色提示。纳了闷，于是去本地仓库，也就是上面的打码的user下面的.m2文件夹找，但是并没有找到jar包。那肯定就解析失败啊。此时才注意到上面这个命令行的输出信息是
Installing D:\Users\jian.wang\AppData\Local\Temp\mvninstall5508834578350192072.pom to d:\Users\lpxie\.m2\repository\org\jbarcode\jbarcode\0.2.8\jbarcode-0.2.8.pom
可见，并没有安装到我期望的用户下面去，而是安装到另一个用户下面去。
明白这个之后，解决方法那就简单，在maven的settings.xml文件里面hard code一个绝对路径：
<localRepository>D:\Users\j***ng\.m2\repository</localRepository>
但是为什么maven会把user信息识别出错呢？？？而且我删除那个用户文件夹，重启电脑，都不行，为什么？？？不知道啊！！！

14. mvn install [ERROR]java.lang.OutOfMemoryError: PermGen space”

在编译工程时，内存不够。
解决方法1：
设定环境变量：set MAVEN_OPTS=-Xmx512m -XX:MaxPermSize=128m
解决方法2：
If you want to make this part of your POM for a repeatable build, you can use the fork-variant of a few of the plugins (especially compiler:compile and surefire:test)：
意思是如果你的pom文件有配置compiler插件，可以进一步配置<configuration>属性，如compiler 和 surefire：

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-compiler-plugin</artifactId>
    <version>3.2</version>
    <configuration>
      <fork>true</fork>
      <meminitial>128m</meminitial>
      <maxmem>1024m</maxmem>
      <compilerArgs>
        <arg>-XX:MaxPermSize=256m</arg>
      </compilerArgs>
    </configuration>
</plugin>
<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-surefire-plugin</artifactId>
    <version>2.18</version>
    <configuration>
        <forkCount>1</forkCount>
        <argLine>-Xmx1024m -XX:MaxPermSize=256m</argLine>
    </configuration>
</plugin>

参考stackoverflow

15. 添加非官方repository

虽然maven的官方仓库repository现在已经有11.0M（即1千1百万）个artifactId，但是在我们的日常开发中，还是会遇到在maven的官方仓库找不到所需的gav，但是在非官方repository（比如Jboss）可以找到，此时可以通过配置第三方的repository把jar包下载到本地。
方法：
打开.m2/settings.xml文件，添加：

<profiles>
	<profile>
        <id>jboss</id>
        <repositories>
            <repository>
                <id>jboss-public-repository-group</id>
                <name>JBoss Public Maven Repository Group</name>
                <url>https://repository.jboss.org/nexus/content/repositories/releases</url>
                <layout>default</layout>
                <releases>
                    <enabled>true</enabled>
                    <updatePolicy>never</updatePolicy>
                </releases>
                <snapshots>
                    <enabled>false</enabled>
                    <updatePolicy>never</updatePolicy>
                </snapshots>
            </repository>
        </repositories>

        <pluginRepositories>
            <pluginRepository>
                <id>jboss</id>
                <name>jboss</name>
                <releases>
                    <enabled>false</enabled>
                    <updatePolicy>always</updatePolicy>
                    <checksumPolicy>warn</checksumPolicy>
                </releases>
                <snapshots>
                    <enabled>true</enabled>
                    <updatePolicy>never</updatePolicy>
                    <checksumPolicy>fail</checksumPolicy>
                </snapshots>
                <url>https://repository.jboss.org/nexus/content/repositories/releases</url>
                <layout>default</layout>
            </pluginRepository>
        </pluginRepositories>

    </profile>
</profiles>

即可。

16. 常用 Maven 插件介绍

Maven本质上是一个插件框架，它的核心并不执行任何具体的构建任务，所有这些任务都交给插件来完成。进一步说，每个任务对应一个插件目标（goal），每个插件会有一个或者多个目标。
用户可以通过两种方式调用Maven插件目标。第一种方式是将插件目标与生命周期阶段（lifecycle phase）绑定，这样用户在命令行只是输入生命周期阶段而已，例如Maven默认将maven-compiler-plugin的compile目标与 compile生命周期阶段绑定，因此命令mvn compile实际上是先定位到compile这一生命周期阶段，然后再根据绑定关系调用maven-compiler-plugin的compile目标。第二种方式是直接在命令行指定要执行的插件目标，例如mvn archetype:generate 就表示调用maven-archetype-plugin的generate目标，这种带冒号的调用方式与生命周期无关。
Maven官方有两个插件列表，第一个列表的GroupId为org.apache.maven.plugins，是为官方插件；第二个列表的GroupId为org.codehaus.mojo。
maven-antrun-plugin
maven-antrun-plugin能让用户在Maven项目中运行Ant任务。用户可以直接在该插件的配置以Ant的方式编写Target， 然后交给该插件的run目标去执行。在一些由Ant往Maven迁移的项目中，该插件尤其有用。此外当你发现需要编写一些自定义程度很高的任务，同时又觉 得Maven不够灵活时，也可以以Ant的方式实现之。maven-antrun-plugin的run目标通常与生命周期绑定运行。

maven-archetype-plugin
Archtype指项目的骨架，Maven初学者最开始执行的Maven命令可能就是mvn archetype:generate，这实际上就是让maven-archetype-plugin生成一个很简单的项目骨架，帮助开发者快速上手。可能也有人看到一些文档写了mvn archetype:create， 但实际上create目标已经被弃用了，取而代之的是generate目标，该目标使用交互式的方式提示用户输入必要的信息以创建项目，体验更好。 maven-archetype-plugin还有一些其他目标帮助用户自己定义项目原型，例如你由一个产品需要交付给很多客户进行二次开发，你就可以为 他们提供一个Archtype，帮助他们快速上手。

maven-assembly-plugin
maven-assembly-plugin的用途是制作项目分发包，该分发包可能包含了项目的可执行文件、源代码、readme、平台脚本等等。 maven-assembly-plugin支持各种主流的格式如zip、tar.gz、jar和war等，具体打包哪些文件是高度可控的，例如用户可以 按文件级别的粒度、文件集级别的粒度、模块级别的粒度、以及依赖级别的粒度控制打包，此外，包含和排除配置也是支持的。maven-assembly- plugin要求用户使用一个名为assembly.xml的元数据文件来表述打包，它的single目标可以直接在命令行调用，也可以被绑定至生命周期。

maven-dependency-plugin
maven-dependency-plugin最大的用途是帮助分析项目依赖，dependency:list能够列出项目最终解析到的依赖列表，dependency:tree能进一步的描绘项目依赖树，dependency:analyze可以告诉你项目依赖潜在的问题，如果你有直接使用到的却未声明的依赖，该目标就会发出警告。maven-dependency-plugin还有很多目标帮助你操作依赖文件，例如dependency:copy-dependencies能将项目依赖从本地Maven仓库复制到某个特定的文件夹下面。

maven-enforcer-plugin
在一个稍大一点的组织或团队中，你无法保证所有成员都熟悉Maven，那他们做一些比较愚蠢的事情就会变得很正常，例如给项目引入了外部的 SNAPSHOT依赖而导致构建不稳定，使用了一个与大家不一致的Maven版本而经常抱怨构建出现诡异问题。maven-enforcer- plugin能够帮助你避免之类问题，它允许你创建一系列规则强制大家遵守，包括设定Java版本、设定Maven版本、禁止某些依赖、禁止 SNAPSHOT依赖。只要在一个父POM配置规则，然后让大家继承，当规则遭到破坏的时候，Maven就会报错。除了标准的规则之外，你还可以扩展该插 件，编写自己的规则。maven-enforcer-plugin的enforce目标负责检查规则，它默认绑定到生命周期的validate阶段。

maven-help-plugin
maven-help-plugin是一个小巧的辅助工具，最简单的help:system可以打印所有可用的环境变量和Java系统属性。help:effective-pom和help:effective-settings最 为有用，它们分别打印项目的有效POM和有效settings，有效POM是指合并了所有父POM（包括Super POM）后的XML，当你不确定POM的某些信息从何而来时，就可以查看有效POM。有效settings同理，特别是当你发现自己配置的 settings.xml没有生效时，就可以用help:effective-settings来验证。此外，maven-help-plugin的describe目标可以帮助你描述任何一个Maven插件的信息，还有all-profiles目标和active-profiles目标帮助查看项目的Profile。

maven-release-plugin
maven-release-plugin，帮助自动化项目版本发布，它依赖于POM中的SCM信息。release:prepare用来准备版本发布，具体的工作包括检查是否有未提交代码、检查是否有SNAPSHOT依赖、升级项目的SNAPSHOT版本至RELEASE版本、为项目打标签等。release:perform则是签出标签中的RELEASE源码，构建并发布。maven-release-plugin的各种目标通常直接在命令行调用，因为版本发布显然不是日常构建生命周期的一部分。

maven-resources-plugin
为了使项目结构更为清晰，Maven区别对待Java代码文件和资源文件，maven-compiler-plugin用来编译Java代码，maven-resources-plugin则用来处理资源文件。默认的主资源文件目录是src/main/resources，很多用户会需要添加额外的资源文件目录，这个时候就可以通过配置maven-resources-plugin来实现。此外，资源文件过滤也是Maven的一大特性，你可以在资源文件中使用${propertyName}形式的Maven属性，然后配置maven-resources-plugin开启对资源文件的过滤，之后就可以针对不同环境通过命令行或者Profile传入属性的值，以实现更为灵活的构建。

maven-surefire-plugin
可能是由于历史的原因，Maven 2/3中用于执行测试的插件不是maven-test-plugin，而是maven-surefire-plugin。其实大部分时间内，只要你的测试 类遵循通用的命令约定（以Test结尾、以TestCase结尾、或者以Test开头），就几乎不用知晓该插件的存在。然而在当你想要跳过测试、排除某些 测试类、或者使用一些TestNG特性的时候，了解maven-surefire-plugin的一些配置选项就很有用了。例如 mvn test -Dtest=FooTest 这样一条命令的效果是仅运行FooTest测试类，这是通过控制maven-surefire-plugin的test参数实现的。

build-helper-maven-plugin
Maven默认只允许指定一个主Java代码目录和一个测试Java代码目录，虽然这其实是个应当尽量遵守的约定，但偶尔你还是会希望能够指定多个 源码目录（例如为了应对遗留项目），build-helper-maven-plugin的add-source目标就是服务于这个目的，通常它被绑定到 默认生命周期的generate-sources阶段以添加额外的源码目录。需要强调的是，这种做法还是不推荐的，因为它破坏了 Maven的约定，而且可能会遇到其他严格遵守约定的插件工具无法正确识别额外的源码目录。
build-helper-maven-plugin的另一个非常有用的目标是attach-artifact，使用该目标你可以以classifier的形式选取部分项目文件生成附属构件，并同时install到本地仓库，也可以deploy到远程仓库。

exec-maven-plugin
exec-maven-plugin很好理解，顾名思义，它能让你运行任何本地的系统程序，在某些特定情况下，运行一个Maven外部的程序可能就是最简单的问题解决方案，这就是exec:exec的 用途，当然，该插件还允许你配置相关的程序运行参数。除了exec目标之外，exec-maven-plugin还提供了一个java目标，该目标要求你 提供一个mainClass参数，然后它能够利用当前项目的依赖作为classpath，在同一个JVM中运行该mainClass。有时候，为了简单的 演示一个命令行Java程序，你可以在POM中配置好exec-maven-plugin的相关运行参数，然后直接在命令运行mvn exec:java 以查看运行效果。

jetty-maven-plugin
在进行Web开发的时候，打开浏览器对应用进行手动的测试几乎是无法避免的，这种测试方法通常就是将项目打包成war文件，然后部署到Web容器 中，再启动容器进行验证，这显然十分耗时。为了帮助开发者节省时间，jetty-maven-plugin应运而生，它完全兼容 Maven项目的目录结构，能够周期性地检查源文件，一旦发现变更后自动更新到内置的Jetty Web容器中。做一些基本配置后（例如Web应用的contextPath和自动扫描变更的时间间隔），你只要执行 mvn jetty:run ，然后在IDE中修改代码，代码经IDE自动编译后产生变更，再由jetty-maven-plugin侦测到后更新至Jetty容器，这时你就可以直接 测试Web页面了。需要注意的是，jetty-maven-plugin并不是宿主于Apache或Codehaus的官方插件，因此使用的时候需要额外 的配置settings.xml的pluginGroups元素，将org.mortbay.jetty这个pluginGroup加入。

versions-maven-plugin
很多Maven用户遇到过这样一个问题，当项目包含大量模块的时候，为他们集体更新版本就变成一件烦人的事情，到底有没有自动化工具能帮助完成这件 事情呢？（当然你可以使用sed之类的文本操作工具，不过不在本文讨论范围）答案是肯定的，versions-maven- plugin提供了很多目标帮助你管理Maven项目的各种版本信息。例如最常用的，命令 mvn versions:set -DnewVersion=1.1-SNAPSHOT 就能帮助你把所有模块的版本更新到1.1-SNAPSHOT。该插件还提供了其他一些很有用的目标，display-dependency- updates能告诉你项目依赖有哪些可用的更新；类似的display-plugin-updates能告诉你可用的插件更新；然后use- latest-versions能自动帮你将所有依赖升级到最新版本。最后，如果你对所做的更改满意，则可以使用 mvn versions:commit 提交，不满意的话也可以使用 mvn versions:revert 进行撤销。