插件执行不受M2E生命周期配置问题，怎么解决

我们都知道Maven可以很容易的把源文件工程创建为War包，但是POM文件中什么也没有设置。这是怎么回事啊？实际上Maven有自己默认的设置。这称之为 “convention over configuration”，Maven在配置中提供默认值。
第一，因为有一些Maven插件本身就与Maven 的生命周期绑定在一起。例如，在编译阶段使用
compiler：compile 作为默认命令。这就意味着当执行到编译阶段compiler plugin 被调用执行。如果选择生成WAR，那么 war：war 会与这个阶段绑定。
第二，当没有明确设置参数的时候，插件都会有自己默认值。例如 compiler：compile 目标有个参数是 compilerId。当默认值是 javac就意味着JDK 会被使用。当需要生成其他形式时可以重写此配置。
第三，一些设置包含在 Super POM,此文件是POM文件默认继承的。从Mavne3 起 Super POM 被放在
pom-400xml文件里面~

Maven是一个用于项目构建的工具，通过它便捷的管理项目的生命周期。即项目的jar包依赖，开发，测试，发布打包。
下面我自己总结一下它的几个特点，看了这些特点，也许对maven有更多的了解。
1 jar包依赖
这个也许会maven最突出的特点了使用maven不需要上网单独下载jar包，只需要在配置文件pomxml中配置jar包的依赖关系，就可以自动的下载jar包到我们的项目中。这样，别人开发或者使用这个工程时，不需要来回的拷贝jar包，只需要复制这个pomxml就可以自动的下载这些jar包。
而且，我们自己下载jar包，还有可能造成版本的不一致，这样在协同开发的过程中就有可能造成代码运行的不一致。通过使用maven精确的匹配jar包，就不会出现这种问题了。
2 项目坐标
Maven通过特定的标识来定义项目名称，这样既可以唯一的匹配其他的jar包，也可以通过发布，使别人能使用自己的发布产品。这个标识就被叫做坐标，长的其实很普通，就是简单的xml而已：
1 <groupId>comtest</groupId>
2 <artifactId>maventest</artifactId>
3 <version>001-SNAPSHOT</version>
4 <packaging>jar</packaging>
5
6 <name>maventest</name>
7 <url>>1． 更快、更简单
比起 Maven1 那不急不慢的运行速度，Maven2在速度上有了质的飞跃，甚至与Ant相比也毫不逊色（当然，下载不算）。除此之外，"简化工作，使用业界公认的最佳实践"也是是 Maven2 的另一大主题，其他的新特性无处不在体现 Maven2 为简化工作而做出的努力。
2． 更少的配置文件
Maven1 和 Maven2 主要配置文件的对比：
Maven1：projectxml、mavenxml、projectproperties和buildproperties。
Maven2：pomxml和settingsxml。
POM是Maven的核心对象模型，在Maven2中POM已由projectxml转移到pomxml中使用，版本也由3升级为4。对于项目，一般只需要pomxml就行了。
在Maven2中不需要也不提倡使用mavenxml，原因如下：
plugin的易用性的增强。
散布于mavenxml中的内容难以在不同项目间共享，也不利于维护。在Maven2中建议使用自定义的plugin来封装这些内容。
如果仍期望能够使用类似mavenxml的功能，如<preGoal>，请参考Inserting non-standard build steps using preGoals and postGoals。
在Maven2中，配置使用settingsxml，它取代了原有的projectproperties和buildproperties。配置在Maven2中存在两种级别：
用户级，针对 *** 作系统登录用户而言。一般在$home/m2/，对于windows用户，就是目录：C:\Documents and Settings\用户名\m2\settingsxml。
全局级：一般在%M2_HOME%/conf/settingsxml，M2_HOME是Maven2的根目录环境变量名。
在settingsxml中可以配置，如本地Repository、proxy等等，关于settingsxml的结构可以从Maven的官方网站上获取。
3． Plugin语言更换
在Maven2中，编写plugin的语言由jelly变更为Java和BeanShell。Java在速度上更有优势，而且开发人员的熟悉程度更高。对于其他的流行脚本，如groovy，Maven的官方网站的意见是，等待其更成熟时再考虑
。
4． 提供预定义的目录模板
好的目录结构可以使开发人员更容易理解项目，为以后的维护工作也打下良好的基础。Maven2根据业界公认的最佳目录结构，为开发者提供了缺省的标准目录模板。

使用目录模板，可以使pomxml更简洁。因为Maven2已经根据缺省目录，预定义了相关的动作，而无需人工的干预。以resources目录为例：
src/main/resources，负责管理项目主体的资源。在使用Maven2执行compile之后，这个目录中的所有文件及子目录，会复制到target/classes目录中，为以后的打包提供了方便。
src/test/resources，负责管理项目测试的资源。在使用Maven2执行test-compile之后，这个目录中的所有文件及子目录，会复制到target/test-classes目录中，为后续的测试做好了准备。
这些动作在 Maven1 中，是需要在 mavenxml 中使用<preGoal>或<postGoal>来完成的。如今，完全不需要在pomxml中指定就能够自动完成。在src和test都使用resources，方便构建和测试，这种方式本就已是前人的经验。通过使用Maven2，使这个经验在开发团队中得到普及。
创建标准目录模板，可以通过如下命令：
mvn archetype:create -DgroupId=comcodelinecommons -DartifactId=codelineCommons
groupId和artifactId的含义与Maven1中的含义一样，参数artifactId的值会作为项目根目录的名字。除了建立相应的目录之外，Maven2还会创建缺省的pomxml。
Maven2也考虑到：不同类型的项目需要拥有不同的目录结构。如创建web项目，可以使用命令：
mvn archetype:create -DgroupId=commycompanyapp
-DartifactId=my-webapp
-DarchetypeArtifactId=maven-archetype-webapp
5． 生命周期的引入
在Maven2中有了明确的生命周期概念，而且都提供与之对应的命令，使得项目构建更加清晰明了。主要的生命周期阶段：
validate，验证工程是否正确，所有需要的资源是否可用。
compile，编译项目的源代码。
test-compile，编译项目测试代码。
test，使用已编译的测试代码，测试已编译的源代码。
package，已发布的格式，如jar，将已编译的源代码打包。
integration-test，在集成测试可以运行的环境中处理和发布包。
verify，运行任何检查，验证包是否有效且达到质量标准。
install，把包安装在本地的repository中，可以被其他工程作为依赖来使用
deploy，在整合或者发布环境下执行，将最终版本的包拷贝到远程的repository，使得其他的开发者或者工程可以共享。
generate-sources，产生应用需要的任何额外的源代码，如xdoclet。
如果要执行项目编译，那么直接输入：mvn compile即可，对于其他的阶段可以类推。阶段之间是存在依赖关系（dependency）的，如test依赖test-compile。在执行mvn test时，会先运行mvn test-compile，然后才是mvn test。
6． 新增Dependency Scope
在POM 4中，<dependency>中还引入了<scope>，它主要管理依赖的部署。目前<scope>可以使用5个值：
compile，缺省值，适用于所有阶段，会随着项目一起发布。
provided，类似compile，期望JDK、容器或使用者会提供这个依赖。如servletjar。
runtime，只在运行时使用，如JDBC驱动，适用运行和测试阶段。
test，只在测试时使用，用于编译和运行测试代码。不会随项目发布。
system，类似provided，需要显式提供包含依赖的jar，Maven不会在Repository中查找它。
<scope>的使用举例：
<dependency>
<groupId>hibernate</groupId>
<artifactId>hibernate</artifactId>
<version>303</version>
<scope>test</scope>
</dependency>
7． 传递依赖，简化依赖管理
在Maven1中，需要把依赖所需要的包也一并列出。这对于使用类似如Hibernate的用户来说所 *** 的心太多了，而且也不方便。在Maven2中实现了传递依赖，如此对于Hibernate所依赖的包，Maven2会自动下载，开发人员只需关心Hibernate即可。
注意：只有得到Maven支持的依赖，通常是plugin形式出现，才能获得这个特性。而且对于一些老的plugin，可能由于时间的关系不支持传递依赖。如至少在Maven 201中，对于Hibernate 212，仍然需要显式列出Hibernate 212所依赖的包。

1 关键名词
Project：任何您想build的事物，Maven都可以认为它们是工程。这些工程被定义为工程对象模型(POM，Poject Object Model)。一个工程可以依赖其它的工程；一个工程也可以由多个子工程构成。
POM：POM(pomxml)是Maven的核心文件，它是指示Maven如何工作的元数据文件，类似于Ant中的buildxml文件。POM文件位于每个工程的根目录中。
GroupId：groupId是一个工程的在全局中唯一的标识符，一般地，它就是工程名。groupId有利于使用一个完全的包名，将一个工程从其它有类似名称的工程里区别出来。
Artifact：artifact 是工程将要产生或需要使用的文件，它可以是jar文件，源文件，二进制文件，war文件，甚至是pom文件。每个artifact都由groupId和 artifactId组合的标识符唯一识别。需要被使用(依赖)的artifact都要放在仓库(见Repository)中，否则Maven无法找到 (识别)它们。
Dependency：为了能够build或运行，一个典型的Java工程会依赖其它的包。在Maven中，这些被依赖的包就被称为dependency。dependency一般是其它工程的artifact。
Plug-in：Maven是由插件组织的，它的每一个功能都是由插件提供的。插件提供goal(类似于Ant中的target)，并根据在POM中找到的元数据去完成工作。主要的Maven插件要是由Java写成的，但它也支持用Beanshell或Ant脚本写成的插件。
Repository：仓库用于存放artifact，它可以是本地仓库，也可以是远程仓库。Maven有一个默认的远程仓库--central，可以从>