java—（2）maven基本命令

均在含pom.xml文件的路径下执行

maven命令执行是按阶段执行的。如执行mvn package。则实际上已经执行了例如以下命令：

假设想执行到test停止。执行mvn test

maven项目类型：

jar：java项目

war：web项目

maven依赖

Maven 下载依赖不仅仅是下载 JAR 文件，它同一时候为这个依赖下载一个 POM 文件

在 Maven 中一个依赖不不过一个 JAR。

它是一个 POM 文件。这个 POM 可能也声明了对其他构件的依赖。这些依赖的依赖叫做传递性依赖。 

1. 创建Maven的普通java项目

• mvn archetype:generate -DgroupId=packageName  -DartifactId=projectName   -DarchetypeArtifactId=maven-archetype-quickstart -DinteractiveMode=false

2. 创建Maven的Web项目 

• mvn archetype:generate -DgroupId=packageName  -DartifactId=webappName -DarchetypeArtifactId=maven-archetype-webapp 

  -DinteractiveMode=false

3. 打jar包在本地Repository中安装jar

• mvn install 

4. 仅仅打jar包

• mvn jar:jar  

5. 測试程序

• java -cp target/my-app-1.0-SNAPSHOT.jar com.mycompany.app.App

6. 查看有效的POM。它暴露了 Maven的默认设置

• mvn help:effective-pom 

7. 生成项目相关信息的报告（target/site文件夹下）

• mvn site                   

8. 忽略測试失败

        

9. 打包时跳过測试

• mvn install -Dmaven.test.skip=true

        

  

        

10. 安装指定文件到本地仓库

• mvn install:install-file -DgroupId=<groupId> -DartifactId=<artifactId> -Dversion=1.0.0 -Dpackaging=jar -Dfile=<myfile.jar>

11. 将项目转化为Eclipse项目

• mvn eclipse:eclipse                

12. 分析项目的依赖信息

• mvn dependency:analyze 
• mvn dependency:tree 打印整个依赖树
• mvn dependency:resolve 打印出已解决依赖的列表
  

13. 查看帮助信息

• mvn help:help 
• mvn help:help -Ddetail=true

14. 调试

• mvn -e            显示具体错误 信息  

• mvn generate-sources    产生应用须要的不论什么额外的源码，如xdoclet。

• mvn install -X 想要查看完整的依赖踪迹。包括那些由于冲突或者其他原因而被拒绝引入的构件，打开 Maven 的调试标记执行

15. 清除产生的项目

• mvn clean 

  （删除target文件夹下编译内容）

16. 在应用程序用使用多个存储库

<repositories>    

    <repository>      

        <id>Ibiblio</id>      

        <name>Ibiblio</name>      

        <url>http://www.ibiblio.org/maven/</url>    

    </repository>    

    <repository>      

        <id>PlanetMirror</id>      

        <name>Planet Mirror</name>      

        <url>http://public.planetmirror.com/pub/maven/</url>    

    </repository>  

</repositories>

17. Maven项目编译步骤

1. 第一、main文件夹下的主代码编写完成后。使用Maven进行编译，在项目根文件夹下执行命令mvn clean compile进行项目编译。
2. 第二、test文件夹下的測试用例编写完成之后就能够调用Maven执行測试，执行mvn clean test进行測试。
3. 第三、将项目进行编译、測试之后。下一个重要步骤就是打包（package）。在pom.xml中定义<packaging>war</packaging>标签表示将要把project打成什么类型的包(默认是jar类型)，我们能够简单地执行命令mvn clean package进行打包。

4. 第四、至此，我们得到了项目的输出，假设我们把项目打成了jar文件而且须要在其它项目中使用的话，就能够复制这个jar文件到其它项目的Classpath中从而使用这个项目中的类。可是。怎样才干让其它的Maven项目直接引用这个jar呢？我们还须要一个安装的步骤，运行mvn clean install命令。

5. 第五、假设项目中有一个拥有main方法的类须要被调用运行。默认打包生成的jar是不可以直接运行的main方法的。由于带有main方法的类信息不会加入到manifest中(我们可以打开jar文件里的META-INF/MANIFEST.MF 文件，将无法看到Main-Class一行)。

   为了生成可运行的jar文件。我们须要借助maven-shade-plugin插 件，配置该插件例如以下：

 <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>com.todaytech.framework.utils.VoConvertXmlUtils</mainClass>
            </transformer>
          </transformers>
        </configuration>
      </execution>
    </executions>
   </plugin>

  

   plugin元素在POM中的相对位置应该在<project><build><plugins>以下。我们配置了mainClass com.todaytech.framework.utils.VoConvertXmlUtils ，项目在打包时会将该信息放到MANIFEST中。现在执行 mvn clean install。待构建完毕之后打开target/文件夹，我们能够看到S3h3WebWs-0.0.1-SNAPSHOT.jar和original-S3h3WebWs-0.0.1-SNAPSHOT.jar，前者是带有Main-Class信息的可执行jar。后者是原始的jar，打开hello-world-1.0-SNAPSHOT.jar的META-INF/MANIFEST.MF。能够看到它包括这样一行信息：Main-Class: com.todaytech.framework.utils.VoConvertXmlUtils。

如今，我们在项目根文件夹中运行该jar文件：

   D: codeS3h3WebWs>java -jar targetS3h3WebWs-0.0.1-SNAPSHOT.jar

   Hello Maven

   控制台输出为Hello Maven。这正是我们所期望的。

在pom.xml文件里添加servlet容器的插件：

<build>
 <plugins>
  <plugin>
   <groupId>org.codehaus.mojo</groupId>
   <artifactId>tomcat-maven-plugin</artifactId>
  </plugin>
  <plugin>
    <groupId>org.mortbay.jetty</groupId>
    <artifactId>maven-jetty-plugin</artifactId>
    <version>6.1.6</version>
  </plugin>
  <plugin>
    <artifactId>maven-compiler-plugin</artifactId>
   <configuration>
   <source>1.6</source>
   <target>1.6</target>
   <encoding>UTF-8</encoding>
   </configuration>
  </plugin>
 </plugins>
</build>

 

启动tomcat:

mvn tomcat:run

 

启动jetty:

mvn jetty:run

POM间关系

• 依赖关系(dependencies)

依赖关系举例： 

<dependency>
   <groupId>org.hibernate</groupId>
   <artifactId>hibernate</artifactId>
   <version>3.2.6.ga</version>
 </dependency>

• 继承关系(parent)

继承关系举例：

继承其它pom.xml配置的内容。

maven提供了一个类似java.lang.Object的顶级父pom.xml文件。

能够通过以下命令查看当前pom.xml受到超pom.xml文件的影响：mvn help:effective-pom。

创建一个各种项目可复用的pom.xml文件。

部署要复用的pom.xml文件：mvn install。

在自己的pom文件里继承上述pom：

 <parent>
   <groupId>com.easymorse</groupId>
   <artifactId>pom</artifactId>
   <version>0.1</version>
</parent>

• 聚合关系(modules)

聚合关系举例：

用于将多个maven项目聚合为一个大的项目。 比方文件夹结构例如以下：

 . |-- pom.xml |-- module-a `-- pom.xml |-- module-b `-- pom.xml |-- module-c `-- pom.xml |-- foo-all `-- pom.xml

那么总的pom.xml文件类似：

 ... <modules>
      <module>module-a</module>
      <module>module-b</module>
      <module>module-c</module>
      <module>foo-all</module>
    </modules>

把项目部署到tomcat下的做法：

tomcat配置有管理权限的用户：conf	omcat-users.xml。
  
<?xml version='1.0' encoding='utf-8'?>
<tomcat-users>
  <role rolename="manager"/>
  <user username="marshal" password="password" roles="manager"/>
</tomcat-users>
在pom文件的tomcat插件中加入：
<plugin>
    <groupId>org.codehaus.mojo</groupId>
    <artifactId>tomcat-maven-plugin</artifactId>
    <configuration>
        <url>http://localhost:8080/manager</url>
        <server>myserver</server>
        <path>/mycontext</path>
    </configuration>
</plugin>
在.m2/settings.xml文件里添加：
<settings 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/settings-1.0.0.xsd">
        <servers>
            <server>
                <id>myserver</id>
                <username>marshal</username>
                <password>password</password>
            </server>
        </servers>
</settings>

• 执行打包部署。在maven项目文件夹下：  mvn tomcat:deploy
• 撤销部署：  mvn tomcat:undeploy
• 启动web应用：mvn tomcat:start
• 停止web应用：mvn tomcat:stop
• 又一次部署：mvn tomcat:redeploy
• 部署展开的war文件：  mvn war:exploded tomcat:exploded

Pom文件解释

pom是指project object Model。

pom是一个xml，在maven2里为pom.xml。是maven工作的基础。在运行task或者goal时，maven会去项目根文件夹下读取pom.xml获得须要的配置信息。

pom文件里包括了项目的信息和maven build项目所需的配置信息，通常有项目信息(如版本号、成员)、项目的依赖、插件和goal、build选项等等。

pom是能够继承的。通常对于一个大型的项目或是多个module的情况，子模块的pom须要指定父模块的pom。

Project pom文件的顶级元素

modelVersion 所使用的object model版本号。为了确保稳定的使用，这个元素是强制性的。除非maven开发人员升级模板，否则不须要改动。

 

groupId 是项目创建团体或组织的唯一标志符，一般是域名倒写，如groupId  org.apache.maven.plugins就是为全部maven插件预留的。 

artifactId 是项目artifact唯一的基地址名。

packaging artifact打包的方式。如jar、war、ear等等。默觉得jar。这个不仅表示项目终于产生何种后缀的文件。也表示build过程使用什么样的lifecycle。

version artifact的版本号，通常能看见为类似0.0.1-SNAPSHOT，当中SNAPSHOT表示项目开发中。为开发版本号。

name 表示项目的展现名，在maven生成的文档中使用。

url表示项目的地址，在maven生成的文档中使用。

description 表示项目的描写叙述，在maven生成的文档中使用。

dependencies 表示依赖。在子节点dependencies中加入详细依赖的groupId artifactId和version。

build 表示build配置。

parent 表示父pom。

当中groupId:artifactId:version唯一确定了一个artifact。

Artifact构件（jar、war、pom）

这个有点不好解释。大致说就是一个项目将要产生的文件，能够是jar文件，源文件。二进制文件，war文件，甚至是pom文件。每一个artifact都由groupId:artifactId:version组成的标识符唯一识别。须要被使用(依赖)的artifact都要放在仓库(见Repository)中。

Repositories（仓库）

Repositories是用来存储Artifact的。

假设说我们的项目产生的Artifact是一个个小工具，那么Repositories就是一个仓库，里面有我们自己创建的工具，也能够储存别人造的工具，我们在项目中须要使用某种工具时。在pom中声明dependency，编译代码时就会依据dependency去下载工具（Artifact），供自己使用。

对于自己的项目完毕后能够通过mvn install命令将项目放到仓库（Repositories）中

仓库分为本地仓库和远程仓库。远程仓库是指远程server上用于存储Artifact的仓库。本地仓库是指本机存储Artifact的仓库，对于windows机器本地仓库地址为系统用户的.m2/repository以下。

Build Lifecycle（编译过程、生命周期）

是指一个项目build的过程。maven的Build Lifecycle分为三种，分别为default（处理项目的部署）、clean（处理项目的清理）、site（处理项目的文档生成）。他们都包括不同的lifecycle。

Build Lifecycle是由phases构成的，以下重点介绍default Build Lifecycle几个重要的phase：

• validate 验证项目是否正确以及必须的信息是否可用。

• compile 编译源码；

• test 測试编译后的代码，即运行单元測试代码；

• package 打包编译后的代码。在target文件夹下生成package文件；

• integration-test 处理package以便须要时能够部署到集成測试环境；

• verify 检验package是否有效而且达到质量标准；

• install 安装package到本地仓库，方便本地其他项目使用；

• deploy 部署，拷贝终于的package到远程仓库和替他开发这或项目共享，在集成或公布环境完毕。

以上的phase是有序的（注意实际两个相邻phase之间还有其它phase被省略。完整phase见lifecycle），以下一个phase的运行必须在上一个phase完毕后