Maven实用详解

╰+攻爆jí腚メ 2022-06-18 12:11 213阅读 0赞

一．安装插件及环境（略）

二．添加jar

maven获取jar过程是maven 将从本地资源库获得maven 的本地资源库依赖资源，如果没有找到，然后把它会从默认的 Maven 中央存储库– http://repo1.maven.org/maven2/ 查找下载，如果中央存储也没有怎么办呢。配置远程存储库。地址为https://maven.java.net/content/repositories/。所以配置参数 为

<url>https://maven.java.net/content/repositories/public/</url>

</repository>

</repositories>

现在，Maven的依赖库查询顺序更改为：

1.      在 Maven 本地资源库中搜索，如果没有找到，进入第 2 步，否则退出。

2.      在 Maven 中央存储库搜索，如果没有找到，进入第 3 步，否则退出。

3.      在java.net Maven的远程存储库搜索，如果没有找到，提示错误信息，否则退出。

如何找到 Maven 坐标？

访问 Maven 中心储存库，搜索下载您想要的jar。

1.公开的jar。如spring-conre-3.2.4.jar

<groupId>org.springframework</groupId>

<artifactId>spring-core</artifactId>

<scope>compiler</scope>

</dependency>

注意：groupId:组织名，比如spring的组织名都是org.springframework

artifactId:项目名

version:版本号, 如果“version”标签被忽略，它会自动升级库时当有新的版本时。

type:相应的依赖产品包形式，如jar，war

scope:用于限制相应的依赖范围，包括以下的几种变量：

compile ：默认范围，用于编译

provided：类似于编译，但支持你期待jdk或者容器提供，类似于classpath

runtime:在执行时，需要使用

test:用于test任务时使用

system:需要外在提供相应得元素。通过systemPath来取得

点保存pom.xml后maven会自动按本地和远程仓库的顺序下载jar。保存路径即是org/springframework/3.2.4/…

2.如果是自己写的或下载不下来的Jar有2种方式。

2.1安装到maven本地代码仓库里。

mvn install:install-file -Dfile=d:\\libs\\mybatis-3.2.5.jar-DgroupId=org.apache -DartifactId=mybatis -Dversion=3.2.5 -Dpackaging=jar

安装完成后再在pom.xml里添加依赖。

2.2  Pom.xml里直接使用systemPath

<groupId>org.mybatis</groupId>

<artifactId>mybatis</artifactId>

<scope>system</scope>

<systemPath>\[绝对路径\]\\\\mybatis-3.2.5.jar</systemPath>

</dependency>

三．生命周期

Maven强大的一个重要的原因是它有一个十分完善的生命周期模型(lifecycle)，这个生命周期可以从两方面来理解，第一，顾名思义，运行Maven的每个步骤都由它来定义的，这种预定义的默认行为使得我们使用Maven变得简单，相比而言，Ant的每个步骤都要你手工去定义。第二，这个模型是一种标准，在不同的项目中，使用Maven的接口是一样的，这样就不用去仔细理解每个项目的构建了，一般情况下，mvn clean install 这样的命令是通用的。

Maven有三套相互独立的生命周期，即三个分开执行的过程，没必要想像成一个整体.这三套生命周期分别是：

CleanLifecycle 在进行真正的构建之前进行一些清理工作。

DefaultLifecycle 构建的核心部分，编译，测试，打包，部署等等。

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

我再次强调一下它们是相互独立的，你可以仅仅调用clean来清理工作目录，仅仅调用site来生成站点。当然你也可以直接运行 mvn clean install site 运行所有这三套生命周期。生命周期是概念上讲的，使用时生命周期也对应着一个插件，比如mvn clean:clean。是clean生命周期，使用的是clean插件，clean目标（冒号后面是goal）

知道了每套生命周期的大概用途和相互关系以后，来逐个详细看一下每套生命周期，Clean和Site相对比较简单，先解释一下。

每套生命周期都由一组阶段(Phase)组成，我们平时在命令行输入的命令总会对应于一个特定的阶段。比如，运行mvn clean ，这个的clean是Clean生命周期的一个阶段。有点绕？要知道有Clean生命周期，也有clean阶段。Clean生命周期一共包含了三个阶段：

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

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

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

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

下面看一下Site生命周期的各个阶段：

pre-site     执行一些需要在生成站点文档之前完成的工作

site    生成项目的站点文档

post-site     执行一些需要在生成站点文档之后完成的工作，并且为部署做准备

site-deploy     将生成的站点文档部署到特定的服务器上

这里经常用到的是site阶段和site-deploy阶段，用以生成和发布Maven站点，这可是Maven相当强大的功能，Manager比较喜欢，文档及统计数据自动生成，很好看。

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

<table> 
 <tbody> 
 <tr> 
 <td> validate </td> 
 <td> 验证项目是否正确，并且所有必要的信息可用于完成构建过程 </td> 
 </tr> 
 <tr> 
 <td> initialize </td> 
 <td> 建立初始化状态，例如设置属性 </td> 
 </tr> 
 <tr> 
 <td> generate-sources </td> 
 <td> 产生任何的源代码包含在编译阶段 </td> 
 </tr> 
 <tr> 
 <td> process-sources </td> 
 <td> 处理源代码，例如，过滤器值 </td> 
 </tr> 
 <tr> 
 <td> generate-resources </td> 
 <td> 包含在包中产生的资源 </td> 
 </tr> 
 <tr> 
 <td> process-resources </td> 
 <td> 复制和处理资源到目标目录，准备打包阶段 </td> 
 </tr> 
 <tr> 
 <td> compile </td> 
 <td> 编译该项目的源代码 </td> 
 </tr> 
 <tr> 
 <td> process-classes </td> 
 <td> 从编译生成的文件提交处理，例如：Java类的字节码增强/优化 </td> 
 </tr> 
 <tr> 
 <td> generate-test-sources </td> 
 <td> 生成任何测试的源代码包含在编译阶段 </td> 
 </tr> 
 <tr> 
 <td> process-test-sources </td> 
 <td> 处理测试源代码，例如，过滤器任何值 </td> 
 </tr> 
 <tr> 
 <td> test-compile </td> 
 <td> 编译测试源代码到测试目标目录 </td> 
 </tr> 
 <tr> 
 <td> process-test-classes </td> 
 <td> 处理测试代码文件编译生成的文件 </td> 
 </tr> 
 <tr> 
 <td> test </td> 
 <td> 运行测试使用合适的单元测试框架（JUnit） </td> 
 </tr> 
 <tr> 
 <td> prepare-package </td> 
 <td> 执行必要的任何操作的实际打包之前准备一个包 </td> 
 </tr> 
 <tr> 
 <td> package </td> 
 <td> 提取编译后的代码，并在其分发格式打包，如JAR，WAR或EAR文件 </td> 
 </tr> 
 <tr> 
 <td> pre-integration-test </td> 
 <td> 完成执行集成测试之前所需操作。例如，设置所需的环境 </td> 
 </tr> 
 <tr> 
 <td> integration-test </td> 
 <td> 处理并在必要时部署软件包到集成测试可以运行的环境 </td> 
 </tr> 
 <tr> 
 <td> pre-integration-test </td> 
 <td> 完成集成测试已全部执行后所需操作。例如，清理环境 </td> 
 </tr> 
 <tr> 
 <td> verify </td> 
 <td> 运行任何检查，验证包是有效的，符合质量审核规定 </td> 
 </tr> 
 <tr> 
 <td> install </td> 
 <td> 将包安装到本地存储库，它可以用作当地其他项目的依赖 </td> 
 </tr> 
 <tr> 
 <td> deploy </td> 
 <td> 复制最终的包到远程仓库与其他开发者和项目共享 </td> 
 </tr> 
 </tbody> 
</table>

verify

install     将包安装至本地仓库，以让其它项目依赖。

deploy     将最终的包复制到远程的仓库，以让其它开发人员与项目共享。

基本上，根据名称我们就能猜出每个阶段的用途，关于其它阶段的解释，请参考http://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html

记住，运行任何一个阶段的时候，它前面的所有阶段都会被运行，这也就是为什么我们运行mvn install 的时候，代码会被编译，测试，打包。

此外，Maven的插件机制是完全依赖Maven的生命周期的，因此理解生命周期至关重要，在之后的文章里，我将会进一步解释Maven的插件机制。

生命周期和goal,阶段（phase）关系，生命周期是个概念，体现是插件的选择上，阶段有现成规则，阶段是已经规定好的顺序和名字，phase其实就是goal的容器。实际被执行的都是goal。phase被执行时，实际执行的都是被绑定到该phase的goal。因为当pom.xml里<packaging>jar</packaging>配置不一样是，同样的打包和编译的方式是不一样的，怎么体现区别了，就靠goal区别。插件是phase是按规则选的，不同的packaging值就靠goal来区分。该阶段具体做什么，goal相当于真正执行的程序。通过xml里绑定goal到某个阶段.,只有到达这个阶段才能执行该goal,每个阶段都有一些默认的goal.当在命令行执行maven命令时,当没指定goal时执行阶段的默认goal,如果用冒号指定则只执行该goal。

四．插件

4.1运行插件2种方式：

命令行方式执行插件：

mvn cleanpackage: 清理目标目录（clean），然后打包项目生成 JAR（包）输出,maven先编译源文件，再测试源文件（junit方式），最好maven打包jar包。

Pom.xml里方式执行插件：

<build>

<groupId>org.apache.maven.plugins</groupId>

<artifactId>maven-antrun-plugin</artifactId>

<id>id.clean</id>

<phase>clean</phase>

<goals>

</goals>

<tasks>

<echo>cleanphase</echo>

</tasks>

</configuration>

</execution>

</executions>

</plugin>

</plugins>

</build>

4.2常见插件：

clean:       编译后的清理目标，删除目标目录. Mvn clean

compiler  编译 Java 源文件mvn compile

surefile     运行JUnit单元测试，创建测试报告mvn site

jar    从当前项目构建 JAR 文件

war  从当前项目构建 WAR 文件

javadoc    产生用于该项目的 Javadoc

antrun      从构建所述的任何阶段运行一组 Ant 任务

mvn dependency:tree> tree.txt  :分析依赖并导出分析结果到tree.txt里

4.3插件使用

clean: 把“target”文件夹中的一切都将被删除,.要部署您的项目进行生产，它总是建议使用 “mvn cleanpackage“, 以确保始终获得最新的部署。

命令行式：mvn clean:clean或mvn clean

Xml行式：<plugin>

<artifactId>maven-clean-plugin</artifactId>

<id>auto-clean</id>

<phase>initialize</phase>

<goals>

<goal>clean</goal>

</goals>

</execution>

</executions>

</plugin>

运行阶段是initialize

执行方式也是命令行等式。

Dependency：

还有一个比较常用的插件就是这个。我们在IDE的环境里编译和执行代码的时候，那是直接引用一些类库。但是在我们实际部署的环境里，那边很可能就一个java执行环境，不可能有源代码和IDE。这个时候，我们需要将源代码编译打包。这个时候的一个问题就是如果我们引用的库很多的话，我们希望能够把他们统一打包到一个目录下，比如lib文件夹。这样部署执行的时候只需要将编译生成的程序jar包和依赖包文件夹拷到特定目录去执行。要实现这个效果也比较容易。

<groupId>org.apache.maven.plugins</groupId>

<artifactId>maven-dependency-plugin</artifactId>

<phase>install</phase>

<goals>

<goal>copy-dependencies</goal>

</goals>

<outputDirectory>$\{project.build.directory\}/lib</outputDirectory>

</configuration>

</execution>

</executions>

</plugin>

从前面的配置里我们可以看到，插件的执行被配置到install这个阶段。这样，当我们执行命令：mvn clean install 的时候，会发现对应的target目录里生成了对应的jar包和依赖包。

install:打包项目，并自动部署到本地资源库，让其他开发人员使用它.

命令行: maven install

xml:

maven-antrun-plugin插件:

maven-antrun-plugin能让用户在Maven项目中运行Ant任务。用户可以直接在该插件的配置以Ant的方式编写Target，然后交给该插件的run目标去执行。在一些由Ant往Maven迁移的项目中，该插件尤其有用。此外当你发现需要编写一些自定义程度很高的任务，同时又觉得Maven不够灵活时，也可以以Ant的方式实现之。maven-antrun-plugin的run目标通常与生命周期绑定运行,只有一个goal即run

六.maven和tomcat

将maven项目依赖的jar包一起发布到tomcat里:

设置一下eclipse：

项目—> properties -> Deployment Assembly -> Add -> Java BuildPath Entries -> 选择Maven Dependencies -> Finish -> OK

把对应的Maven依赖包也发布到tomcat，调试时会自动把那些jar发布到指定目录下，tomcat也能找到那些jar了。

写的不好，尽请量解。

引用：[http://www.infoq.com/cn/news/2011/05/xxb-maven-8-plugin][http_www.infoq.com_cn_news_2011_05_xxb-maven-8-plugin]

http://www.yiibai.com/maven/

[http_www.infoq.com_cn_news_2011_05_xxb-maven-8-plugin]: http://www.infoq.com/cn/news/2011/05/xxb-maven-8-plugin