Maven

maven-${prefix}-plugin offical

${prefix}-maven-plugin third part

mvn命令参数 ${prefix}:${goal}

运行java程序--mvn exec:java -Dexec.mainClass="your.class"

plugin列表: http://maven.apache.org/plugins/index.html

创建项目框架： mvn archetype:generate -DarchetypeCatalog=internal(默认使用远程仓库的Catalog)

============================================================================================

Maven 文章：

Maven简介（一）——Maven的安装和settings.xml的配置 https://blog.csdn.net/zp522123428/article/details/41041413

maven打包总结 https://blog.csdn.net/fireofjava/article/details/14447325

============================================================================================

Maven工作原理Build Lifecycle:

Maven 2是围绕着Build Lifecycle概念设计的。这意味着，构建或者发布的过程已经被清晰的定义了。

 

Build lifecycle是由a set有依次顺序的phases组成的 。当我们使用Maven构建工程时，我们只需要了解自己希望做什么，然后执行对应的lifecycle phase即可。

 

例如，我们希望编译我们的工程，在命令行状态下 进入到工程的pom.xml文件所在的目录中 ，使用命令: mvn compile ；希望构建打包我们的工程，使用mvn package即可。

 

每个LifeCycle phase实质上都会绑定到某个plugin:goal上！！ 例如命令

mvn compile

实际上等价于

             mvn compiler:compile

即执行compile phase命令＝执行compiler plugin的compile goal

 

但有一个很关键的知识点： pom.xml的<packaging>的值不同，会影响lifecycle phase与哪个plugin:goal的绑定。 例如：

如果是

<packaging>jar</packaging>

那么

package phase绑定到jar:jar

则

            mvn package = mvn jar:jar

           

如果是

<packaging>war</packaging>

那么

package phase绑定到war:war

则

            mvn package = mvn war:war

 

 

在 default  lifecycle 里，包含下列最常用被执行的phases （文章最后会给出lifecycle phases的完整列表） ：

• validate : validate the project is correct and all necessary information is available
• compile : compile all java files in project
• test : 使用unit test framework来test the compiled source code。这些test class不会被packaged and deployed。
• package : 把compiled code打包成你需要的格式，如JAR.
• integration-test : 把已经打包的东东（如jar）deploy到运行环境内，用于集成测试
• verify : run any checks to verify the package is valid and meets quality criteria
• install : install the package into the local repository, 这样做的目的是作为其他projects的一个local dependency
• deploy : 该phase会copy final package到remote repository for sharing。This phase is done in an integration or release environment。

另外还有3个很常用的、但不属于default lifecycle的phase：

• clean : cleans up artifacts created by prior builds

• site : generates site documentation for this project
• eclipse:eclipse : 创建相关的eclipse ide文件  

 

当你执行一个phase命令时，maven就会执行顺序排在该phase之前的所有phases，然后再执行该phase。 例如，如果我们执行“ compile ” phase，那么maven实际要执行的phases依次为：

1.         validate

2.         generate-sources

3.         process-sources

4.         generate-resources

5.         process-resources

6.         compile

 

一个mvn命令可以同时执行多个phases ，如：

mvn clean install

该命令是先执行clean phase，然后执行install phase

 

 

<packaging>与lifecycle phase

pom.xml的<packaging>的值(缺省为)会直接影响mvn lifecycle phase的执行操作，即不同的值将直接影响lifecycle phase与哪个plugin:goal的绑定。

 

 

例：

1）如果是<packaging>jar</packaging>，那么lifecycle phases与plugin:goal的绑定为（ 左边为lifecycle phase，右边为实际操作plugin:goal ）：

 

process-resources	resources:resources
compile	compiler:compile
process-test-resources	resources:testResources
Test-compile	compiler:testCompile
Test	surefire:test
package	jar:jar
install	install:install
deploy	deploy:deploy

 

看上面列表，其中 最值得注意的是package phase绑定到了jar:jar上 ，

执行mvn package = mvn jar:jar

 

2）如果是 <packaging>war</packaging> ，那么package phase会绑定到war:war上，执行 mvn package = mvn war:war

 

3）如果是 <packaging>pom</packaging> ，那么上面列表中 只有“install” and “deploy”被绑定到，而其他phases则没有被绑定到。也就是说如果执行mvn package，则什么操作也没执行。

 

 

另外一个很重要的知识点是： 有一些<packaging>值的使用，必须在pom.xml里添加相应的<plugin>配置信息。

 

例如：如果你要使用

<packaging> plexus-application <packaging>

or

<packaging> plexus-service <packaging>

就必须在pom.xml里添加“Plexus” plugin配置。

 

 

<plugin> 与lifecycle phase

 

<plugin> element可以给lifecycle phase添加要执行的goal ，<plugin>设置的goal将会被添加到goal list goals which already bound to the lifecycle from the packaging selected。这时 某个phase被绑定了1个以上的goal，那么在执行该phase的mvn命令时，会先执行<packaging>本身所绑定的goal，然后再执行<plugin>绑定的goals。你更可以使用<plugin>的child element <executions>来控制goal的执行顺序 。

 

例：有一个Modello plugin，它总是绑定modello:java到generate-sources phase（注意： 设置绑定不是在你的pom.xml里，而是plugin本身已经设置好了的！！ ）

 

如果你的project想使用Modello plugin来generate sources from a model，那么就需要在pom.xml里的<build>里的<plugins>里添加下列代码：

 

...

 <plugin>

   <groupId>org.codehaus.modello</groupId>

   <artifactId>modello-maven-plugin</artifactId>

   <executions>

     <execution>

       <configuration>

         <model>maven.mdo</model>

         <modelVersion>4.0.0</modelVersion>

       </configuration>

       <goals>

         <goal>java</goal>

       </goals>

     </execution>

   </executions>

 </plugin>

...

 

为什么要使用<executions>？ 这是因为 使用它可以对同一个goal根据不同的<configuration>来执行多次。

 

如果有多个匹配某个phase的<execution>，那么他们将会被依次按顺序执行（当然，被继承的execution会先被执行）

 

我们再来考虑这样一种情况：上面提到Modello plugin的goal（modello:java）被绑定到generate-sources phase（ 注意：设置绑定不是在你的pom.xml里，而是plugin本身已经设置好了的！！ ）， 如果我还希望该goal能够同时也绑定到另外的、非内在绑定的phase上，怎么办呢 ？很简单， 只需要在<execution>里使用<phase>来设置。 例如，你有一个goal touch:timestamp，它是用来输出某个file的timestamp，该goal内在绑定到test phase，你希望能把它也绑定到process-test-resources上，则使用下列代码：

...

 <plugin>

   <groupId>com.mycompany.example</groupId>

   <artifactId>touch-maven-plugin</artifactId>

   <executions>

     <execution>

       <phase>process-test-resources</phase>

       <configuration>

         <file>${project.output.directory}/timestamp.txt</file>

       </configuration>

       <goals>

         <goal>timestamp</goal>

       </goals>

     </execution>

   </executions>

 </plugin>

...

 

 

lifecycle phases的完整列表(按执行的先后顺序)

validate	validate the project is correct and all necessary information is available.
generate-sources	generate any source code for inclusion in compilation.
process-sources	process the source code, for example to filter any values.
generate-resources	generate resources for inclusion in the package.
process-resources	copy and process the resources into the destination directory, ready for packaging.
compile	compile the source code of the project.
process-classes	post-process the generated files from compilation, for example to do bytecode enhancement on Java classes.
generate-test-sources	generate any test source code for inclusion in compilation.
process-test-sources	process the test source code, for example to filter any values.
generate-test-resources	create resources for testing.
process-test-resources	copy and process the resources into the test destination directory.
test-compile	compile the test source code into the test destination directory
test	run tests using a suitable unit testing framework. These tests should not require the code be packaged or deployed.
prepare-package	perform any operations necessary to prepare a package before the actual packaging. This often results in an unpacked, processed version of the package. (Maven 2.1 and above)
package	take the compiled code and package it in its distributable format, such as a JAR.
pre-integration-test	perform actions required before integration tests are executed. This may involve things such as setting up the required environment.
integration-test	process and deploy the package if necessary into an environment where integration tests can be run.
post-integration-test	perform actions required after integration tests have been executed. This may including cleaning up the environment.
verify	run any checks to verify the package is valid and meets quality criteria.
install	install the package into the local repository, for use as a dependency in other projects locally.
deploy	done in an integration or release environment, copies the final package to the remote repository for sharing with other developers and projects.