maven入门：生命周期和插件Plugins(四)

目录

1.maven生命周期

maven一共有三套生命周期分别是 clean,default,site.每个生命周期有包含多个阶段,每个阶段实际不做任何事情,对应阶段的事情是由绑定到这个阶段的插件来完成的.

生命周期列表:

周期 阶段 解释(“/”请参照官方: Lifecycle Reference) 默认绑定插件目标(内置绑定) clean pre-clean 进行clean前工作 clean 移除所有上一次构建生成的文件 maven-clean-plugin:clean post-clean 进行clean后工作 default validate 验证项目资源等是否可用 generate-sources 产生应用需要的额外的源代码，如xdoclet process-sources / maven-resources-plugin:resources generate-resources / process-resources 复制并处理资源文件，至目标目录，准备打包 compile 编译项目源码 maven-compiler-plugin:compile process-classes / generate-test-sources / process-test-sources 复制并处理资源文件，至目标测试目录 generate-test-resources / process-test-resources / maven-resources-plugin:testResources test-compile 编译测试源码 maven-compiler-plugin:testCompile process-test-classes / test 运行测试代码,但不会被打包部署,没有亲测哈 maven-surefire-plugin:test prepare-package / package 打包 maven-jar-plugin:jar(如果pom中package是jar) pre-integration-test / integration-test 如需要将包处理发布到能进行集成测试的环境 post-integration-test / verify 运行所有检查验证包是否有效且达到质量标准 install 安装到本地仓库 maven-install-plugin:install deploy 上传到远程仓库 maven-deploy-plugin:deploy site pre-site 生成站点文档前完成的工作 site 生成站点文档 maven-site-plugin:site post-site 生成站点文档后完成的工作 site-deploy 将生成站点部署到服务器 maven-site-plugin:deploy

关于生命周期理解需要注意的地方:
(1).clean,default,site是相互独立互不影响
(2).执行后边的阶段,会自动把之前的阶段也都执行.

举例:执行compile的话会依次执行 validate->generate-sources->process-sources->generate-resources->process-resources->compile注意并没有执行clean生命周期的任何阶段.

2.插件目标

maven抽象了生命周期,具体任务又插件完成,插件本身有很多目标,每个目标对应一个功能如dependency:analyze、 dependency:tree和dependency:list 是maven-dependency-plugin目标中的三个.

3.插件绑定

(1).内置绑定(见上方列表)
(2).自定义绑定

<build>       <plugins>           <plugin>               <groupId>插件groupId</groupId>               <artifactId>插件artifactId</artifactId>               <version>插件version</version>               <executions>                   <execution>                       <id>id</id>                       <phase>绑定的阶段,如:compile</phase>                       <goals>                           <goal>执行插件的哪个目标</goal>                       </goals>                   </execution>               </executions>           </plugin>       </plugins>   </build>  

4.插件(updating…)

jetty插件:有了这个插件我们就可以在开发阶段每次不用生成war部署到tomcat了.而且在用这个插件过程总遇到了写问题也引发了思考.我想很多新手很有可能也会遇到所以在这里写一下.
问题描述:A项目引用了B项目,当再IDE(eclipse或者IDEA)中改变了B的java代码后并clean compile B项目,A重启jetty执行时依然是B改之前的代码
问题解决:B改变了java代码后clean install ,然后重启
问题分析:对于maven大家一定要理解启动jetty是maven行为,此时虽然在IDE中可以引用B项目,但在maven中,所有的依赖都是基于工厂的,B改变了代码做了clean compile但是并没有把代码install到本地工厂,或者deploy到远程工厂.所以当重启jetty时本地工厂还是上一次install进去的B项目的jar.
问题补充:jetty在启动时会自动执行default生命中期中的compile阶段.所以install 最新B项目后重启jetty已经自动帮我们compile了A项目,但是为了保险还是建议大家clean compile.

<build>  <plugins>    <plugin>      <groupId>org.mortbay.jetty</groupId>      <artifactId>maven-jetty-plugin</artifactId>      <version>6.1.16</version>      <configuration>        <contextPath>/user</contextPath>        <scanIntervalSeconds>10</scanIntervalSeconds>        <connectors>          <connector implementation="org.mortbay.jetty.nio.SelectChannelConnector">            <port>8080</port>            <maxIdleTime>60000</maxIdleTime>          </connector>        </connectors>        <stopPort>8080</stopPort>        <stopKey>foo</stopKey>      </configuration>    </plugin>  </plugins>  <finalName>user-web</finalName></build>

maven-dependency-plugin插件: 这个插件可以将项目中的jar都拷贝到某一个目录下。对于webapps骨架的项目并不需要这个插件，因为maven会自动根据scope决定是否将jar打入war中。但有时我们需要打一个可执行的jar，这个插件就用到了。打完包后我们程序用的jar就都打到lib下了。

<plugin><groupId>org.apache.maven.plugins</groupId><artifactId>maven-dependency-plugin</artifactId><executions>  <execution>    <id>copy</id>    <phase>package</phase>    <goals>      <goal>copy-dependencies</goal>    </goals>    <configuration>                      <outputDirectory>       ${project.build.directory}/lib     </outputDirectory>    </configuration>  </execution></executions></plugin>

project.build.directory 指的是当前项目的target目录。这样当我们执行完package后lib中会存放所有本项目用到的jar。

maven-jar-plugin插件: 可执行jar的插件
manifest 为可执行jar的main方法入口

<plugin>  <groupId>org.apache.maven.plugins</groupId>  <artifactId>maven-jar-plugin</artifactId>  <version>2.4</version>  <configuration>    <archive>      <manifest>                 <mainClass>         cn.milo.udp.clientdemo.demo       </mainClass>       <!-- 下边两个配置很重要,目的是配置 MANIFEST.MF 中的Class-Path: ,如果不配置,我们的jar包还是找不到上一步lib目录下的依赖. -->       <addClasspath>true</addClasspath>       <classpathPrefix>lib/</classpathPrefix>      </manifest>    </archive>  </configuration></plugin>

5. build中的resources标签

对于webapps骨架src/main/resources中的配置会自动打包到war中，但对于quickstart的骨架，配置文件并不会自动打入可执行jar包中。所以我们可以在build中加入如下配置

<resources>  <resource>    <directory>src/main/resources</directory>    <includes>      <include>*.properties</include>    </includes>    <!--<excludes>-->      <!--<exclude>*.txt</exclude>-->    <!--</excludes>-->  </resource></resources>

includes 是包含的类型，excludes是不包含的类型。