maven学习--基础篇

2016-01-5 16:13:43

发现一些错误，文章修改中……

（部分图片截取自其他地方，不是很清楚）

一、 maven的项目创建和基本命令

maven是一个项目管理工具，包含了一个项目对象模型POM，一组标准集合，一个项目生命周期，一个依赖管理系统，和用来运行定义在生命周期阶段中插件目标的逻辑。

maven遵循约定由于配置的原则，是指maven虽然支持配置方式，但如果有约定好的默认值，比如约定好的目录结构，就使用约定的。

maven的安装不再介绍，验证maven是否安装成功：

安装成功后，maven下有四个目录：

bin:包含运行命令mvn、mvnDebug等，既有在windows下运行的，也有在linux/unix下运行的；

boot:有maven自己开发的类加载器;

lib：maven运行所需要的一些jar包，刚安装maven时，它其实是非常小的，它只安装了自己必须的jar包。对于以后在工作中所需要的插件、jar包，他会根据你的需要不断的进行下载。

conf:配置文件setting.xml，如果在里面改变配置参数的话，它会对所有的系统用户都生效，但我们通常并不希望这件事情发生，我们希望配置只对当前用户生效，所以通常会把settings.xml粘贴到到c盘的.m2下。

 具体的项目创建：

博客http://blog.csdn.net/edward0830ly/article/details/8748986中介绍的很清楚

常用的命令：

mvn compile ：会对src/main目录底下的资源和类进行编译处理，src/main/resources目录中的所有文件及子目录，会复制到target/classes目录中，为以后的打包提供了方便。

mvn test-compile ：只对测试目录底下的类和资源进行处理，但因为测试依赖于main下面的资源和类，所以会先对这些进行处理。src/test/resources目录中的所有文件及子目录，会复制到target/test-classes目录中，为后续的测试做准备。

mvn test ： 执行测试的一个命令，默认情况是把工程所有的testcase都执行一遍。如果需要执行某一个 testcase类，可以通过-Dtest参数。

mvn clean  ：把target目录给清理掉了，很多缓存输出在target文件夹中。

（mvn claen instal l可以避免一些错误的发生，如果不执行clean，而直接install的话，其过程中生成的如.class文件就会覆盖原来的文件，这在一般情况下是没有问题的。但是，比如你在源文件删除了一个java，结果没有clean，则它依然存在与target中，可能会对最终的结果造成影响。）

mvn package ：在target目录下打包；

mvn exec：可以执行项目中的main函数。

（二）maven的生命周期

http://juvenshun.iteye.com/blog/213959

Maven有三套相互独立的生命周期，请注意这里说的是“三套”，而且“相互独立”，初学者容易将Maven的生命周期看成一个整体，其实不然。这三套生命周期分别是：

Clean Lifecycle 在进行真正的构建之前进行一些清理工作；

Default Lifecycle 构建的核心部分，编译，测试，打包，部署等等;

Site Lifecycle 生成项目报告，站点，发布站点。

我再次强调一下它们是相互独立的，你可以仅仅调用clean来清理工作目录，仅仅调用site来生成站点。当然你也可以直接运行 mvn clean install site 运行所有这三套生命周期。

每套生命周期都由一组阶段(Phase)组成，mvn clean ，这个clean是Clean生命周期的一个阶段。Clean生命周期一共包含了三个阶段：

pre-clean  执行一些需要在clean之前完成的工作；

clean  移除所有上一次构建生成的文件；

post-clean  执行一些需要在clean之后立刻完成的工作。

注意：

在一个生命周期中，运行某个阶段的时候，它之前的所有阶段都会被运行，也就是说，mvn clean 等同于 mvn pre-clean clean ，如果我们运行 mvn post-clean ，那么 pre-clean，clean 都会被运行。这是Maven很重要的一个规则，可以大大简化命令行的输入。

Site生命周期的各个阶段：

• pre-site     执行一些需要在生成站点文档之前完成的工作
• site    生成项目的站点文档
• post-site     执行一些需要在生成站点文档之后完成的工作，并且为部署做准备
• site-deploy     将生成的站点文档部署到特定的服务器上

对于Maven的最重要的Default生命周期，绝大部分工作都发生在这个生命周期中，这里，只解释一些比较重要和常用的阶段：

• process-resources     复制并处理资源文件，至target目标目录，准备打包。
• compile     编译项目的源代码。
• process-test-resources     复制并处理资源文件，至target目标测试目录。
• test-compile     编译测试源代码。
• test     使用合适的单元测试框架运行测试。这些测试代码不会被打包或部署。
• package     接受编译好的代码，打包成可发布的格式，如 JAR 。
• install     将包安装至本地仓库，以让其它项目依赖。
• deploy     将最终的包复制到远程的仓库，以让其它开发人员与项目共享。

（三）POM （project object model）

Pom其实就是一个xml文件，写在节点<project></project>里面

<project 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/maven-4.0.0.xsd">
  <modelVersion>4.0.0</modelVersion>

  <groupId>com.test.maven</groupId>
  <artifactId>test1</artifactId>
  <version>0.0.1-SNAPSHOT</version>
  <packaging>jar</packaging>

  <name>test1</name>
  <url>http://maven.apache.org</url>

  <properties>
    <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
  </properties>

  <dependencies>
    <dependency>
      <groupId>junit</groupId>
      <artifactId>junit</artifactId>
      <version>3.8.1</version>
      <scope>test</scope>
    </dependency>
  </dependencies>
</project>

其中，modelVersion：maven的默认版本

groupId：创建组织的标识符，一般是域名的倒写

artifactId：定义了项目在所属组织下的唯一标识，一个组织下可以有多个项目

version：当前项目的版本，SNAPSHOT，表示是快照版本，在开发中

url：这个项目所在的网页地址

properties：指定这个工程在创建或编译的时候所使用的编码格式

dependencies：这里添加了对junit的依赖

scope：确定junit在什么范围内生效。

complie:默认使用该依赖，对编译、测试、运行三种classpath都有效；

test：只对测试时有效，如这里的junit;

provided：在运行时无效，对编译和测试有效，如servlet-api;

runtime：如jdbc，对测试和运行有效，在编译时无效。

除了在上述pom.xml中配置依赖，使需要的jar包加载到本地仓库中，还可以手动加载，使用前面提过的mvn install命令，下面的例子可以参考

（四）在Eclipse中的应用

将上述POM文件中提到的test1导入到eclipse里：

首先执行命令mvn eclipse:eclipse ，生成 Eclipse 项目文件。将test1转成一个eclipse工程后，我们会发现test1里多了两个文件，一个是.classpath文件，一个是.project文件；

然后在eclipse中导入项目，file—import—exsiting……。

成功将test1导入eclipse后，如果想在这个工程中继续添加对其他的包的依赖，直接打开pom.xml文件进行编辑即可。但如果想删除某一依赖的话，因为在做mvn eclipse:eclipse时都已经添加到classpath中去了，需要在修改pom.xml文件后，再在eclipse中刷新一下，这样工程对包的依赖就改变了。

mvn eclipse:clean  删除增加的.classspath和.project文件，即清除掉eclipse的一些系统设置。

如果开发工具是intelliJ，使用mvn idea:idea，将工程改造成intellij工程。同样的可以使用 mvn idea:clean 来把这个intelliJ工程的信息给删除掉。

（五）maven本地仓库转移

本地仓库repository放在c盘其实是不太好的，因为如果要重新安装操作系统的话，仓库就会被格式化掉。

完成仓库的转移：

1、拷贝repository到其他盘下，如D盘;

2、打开.m2下的setting.xml文件（从maven的conf目录下拷贝过去的），找到

 <!-- localRepository
   | The path to the local repository maven will use to store artifacts.
   |
   | Default: ${user.home}/.m2/repository
  <localRepository>/path/to/local/repo</localRepository>
  -->

删除注释，改为<localRepository>D:\repository\</localRepository>

（六）maven插件 

在eclipse上安装maven插件，windows—preference-maven-installation中默认的maven是embedded的，

如果想使用本地maven的话，需要add添加进来。还要注意user settings的文件 ，这里使用的是.m2目录下的settings.xml。

在修改setting后，一定要update setting，并reindex，否则eclipse无法知道对maven的更改，这样在eclipse中使用maven插件会出问题的。

在pom中，可能会有提示功能，例如输入一个尖括号<，会自动出现可以匹配的文本，这是。因为maven插件安装时在xml catalog中加载进了maven 的xml catalog ，如下

（七）超级pom

如果工程需要对spring-beans这个包添加依赖，但本地仓库中没有这个jar包，我们执行编译等命令时可能并没有错误，因为它自动从一个位置下载下来了。

Maven怎么知道从哪下载jar包呢，因为maven有一个超级pom，这个pom是所有pom的父pom。

找到maven的安装目录，在lib底下有这么一个jar包

打开这个包，可以看到pom-4.0.0.xml

在这个文件里就规定了默认仓库的位置的，规定了java工程的目录结构，规定了plugin核心插件的版本（因为要保证maven3.3正常运行，就要保证这些插件的版本和它是匹配的）等等。

最后生效的超级pom和自定义pom叠加产生的有效的pom，即effctive pom，它的内容比我们自定义的pom多的多。

执行命令mvn help:effective-pom可以在命令行中查看effective pom，也可以很方便的在eclipse中查看，下面以hello-world工程为例进行展示：

里面有repositories和PluginRepositories，你还可以在pom中添加自己的repository，将它放在中央仓库的上面。

下面是build构建，这是maven最核心的部分了，

其中包括源代码的目录，测试源代码的目录，输出目录、资源文件的目录等，我们的工程结构就是来自于这个地方。

如何将一个已有的项目（其工程结构并不符合maven工程要求）纳入到maven管理中去呢？显然，移动相应的类、包使他符合maven工程的结构并不现实，一个有效的方法就是自定义pom文件。

再下面是<PluginManagement>，PluginManagement表示插件声明，即你在项目中的PluginManagement下声明了插件，maven不会加载该插件，pluginManagement声明可以被继承。
一个使用案例是当有父子项目的时候，父项目中可以利用PluginManagement声明子项目中需要用到的插件。之后，当子项目需要加载该插件的时候，就可以在子项目中plugins节点只配置 groupId 和 artifactId就可以完成插件的引用。
pluginManagement主要是为了统一管理插件，确保所有子项目使用的插件版本保持一致，类似的还是dependencies和dependencyManagement。

……

<plugins>中的plugin是给当前工程用的，是当前工程即将要使用到的plugin，会告诉你使用的是哪一个plugin，版本是多少以及要执行的阶段、目标。