Maven

XPJ
366 阅读7分钟

前言

Maven作为一个构建工具，不仅能帮我们自动化构建，还能够抽象构建过程，提供构建任务实现；它跨平台，对外提供了一致的操作接口，这一切足以使它成为优秀的、流行的构建工具。Maven不仅是构建工具，还是一个依赖管理工具和项目管理工具，它提供了中央仓库，能帮我自动下载构件。

1、常用命令

图片.png Maven命令可携带的参数类型如下：

1.1、-N

不递归到子项目(子模块)

举例：
一个父项目下Father面有3个子项目A、B、C，都生成jar包，则有Father.jar、A.jar、B.jar、C.jar;  
这个时候A项目依赖了B、C项目。
此时如果使用（mvn clean install -N），则只会把Father.jar安装到本地仓库(~/.m2/repository)，
而不会安装其他三个包

1.2、-U

强制刷新本地仓库不存在release版和所有的snapshots版本。默认每天只更新一次

说明：
1. 对于release版本，本地已经存在，则不会重复下载;
2. 对于snapshots版本，不管本地是否存在，都会强制刷新，但是刷新并不意味着把jar重新下载一遍。只下载几个比较小的文件，通过这几个小文件确定本地和远程仓库的版本是否一致，再决定是否下载

1.3、-D

传入属性参数

比如命令： mvn package -Dmaven.test.skip=true 以-D开头，将maven.test.skip的值设为true,就是告诉maven打包的时候跳过单元测试。同理，mvn deploy-Dmaven.test.skip=true代表部署项目并跳过单元测试。

1.4、-E

显示maven运行出错的信息

1.5、-O

离线执行命令,即不去远程仓库更新包。

1.6、-X

显示maven允许的debug信息

1.7、-P

使用指定的Profile配置。比如：项目开发需要有多个环境，一般为开发，测试，预发，正式4个环境，在pom.xml中的配置如下：

<profiles>
      <profile>
             <id>dev</id>
             <properties>
                    <env>dev</env>
             </properties>
             <activation>
                    <activeByDefault>true</activeByDefault>
             </activation>
      </profile>
      <profile>
             <id>qa</id>
             <properties>
                    <env>qa</env>
             </properties>
      </profile>
      <profile>
             <id>pre</id>
             <properties>
                    <env>pre</env>
             </properties>
      </profile>
      <profile>
             <id>prod</id>
             <properties>
                    <env>prod</env>
             </properties>
      </profile>
</profiles>
 
......
 
<build>
      <filters>
             <filter>config/${env}.properties</filter>
      </filters>
      <resources>
             <resource>
                    <directory>src/main/resources</directory>
                    <filtering>true</filtering>
             </resource>
      </resources>
 
      ......
 
</build>

profiles定义了各个环境的变量id，filters中定义了变量配置文件的地址，其中地址中的环境变量就是上面profile中定义的值，resources中是定义哪些目录下的文件会被配置文件中定义的变量替换。

通过maven可以实现按不同环境进行打包部署，命令为:

mvn package -P dev

其中dev为环境的变量id,代表使用Id为dev的profile。

2、snapshot和release

maven中的仓库分为两种，snapshot快照仓库和release发布仓库。snapshot快照仓库用于保存开发过程中的不稳定版本，release正式仓库则是用来保存稳定的发行版本。定义一个组件/模块为快照版本，只需要在pom文件中在该模块的版本号后加上-SNAPSHOT即可(注意这里必须是大写)，如下：

<groupId>cc.mzone</groupId>
<artifactId>m1</artifactId>
<version>0.1-SNAPSHOT</version>
<packaging>jar</packaging>

2.1、发布时的区别

maven2会根据模块的版本号(pom文件中的version)中是否带有-SNAPSHOT来判断是快照版本还是正式版本。

  1. 如果是快照版本，那么在mvn deploy时会自动发布到快照版本库中，会覆盖老的快照版本，而在使用快照版本的模块，在不更改版本号的情况下，直接编译打包时，maven会自动从镜像服务器上下载最新的快照版本。
  2. 如果是正式发布版本，那么在mvn deploy时会自动发布到正式版本库中，而使用正式版本的模块，在不更改版本号的情况下，编译打包时如果本地已经存在该版本的模块则不会主动去镜像服务器上下载。

2.2、使用时的区别

在maven的约定中，依赖的版本分为两类——SNAPSHOT和RELEASE。SNAPSHOT依赖泛指以-SNAPSHOT为结尾的版本号，例如1.0.1-SNAPSHOT。除此之外，所有非-SNAPSHOT结尾的版本号则都被认定为RELEASE版本，即正式版，虽然会有beta、rc之类说法，但是这些只是软件工程角度的测试版，对于maven而言，这些都是RELEASE版本。

2.2.1、SNAPSHOT

同一个SNAPSHOT版本的依赖可以多次发布（deploy）到仓库中，也就是说同一个SNAPSHOT版本的依赖可以在仓库中存在多份，每一份都是代码在某一个特定时间的快照，这也是SNAPSHOT的含义。SNAPSHOT不是一个特定的版本，而是一系列的版本的集合，其中HEAD总是指向最新的快照，对外界可见的一般也是最新版，这种给人的假象是新的覆盖了老的，从而使得使用SNAPSHOT依赖的客户端总是通过重新构建（有时候需要-U强制更新）就可以拿到最新的代码。

例如：A-->B-1.3.8-SNAPSHOT（理解为A依赖了B的1.3.8-SNAPSHOT版本），那么B-1.3.8-SNAPSHOT更新之后重新deploy到仓库之后，A只需要重新构建就可以拿到最新的代码，并不需要改变依赖B的版本。由此可见，这样达到了变更传达的透明性，这对于开发过程中的团队协作的帮助不言而喻。

注意：SNAPSHOT是变化的，是不稳定的，而应用（软件）依赖于变化并且不稳定的SNAPSHOT的依赖会导致自身也在变化和不稳定中，这是稳定性的一个大忌，依赖不稳定的服务或者依赖。

2.2.2、RELEASE

RELEASE版本和SNAPSHOT是相对的，非SANPSHOT版本即RELEASE版本，RELEASE版本是一个稳定的版本号，看清楚咯，是一个，不是一系列，可以认为RELEASE版本是不可变化的，一旦发布，即永远不会变化。

虽然RELEASE版本是稳定不变的，但是仓库还是有策略让这个原则变得可配置，有的仓库会配置成redeploy覆盖，这样RELEASE版本就变成SNAPSHOT了，伪装成RELEASE的SNAPSHOT，会让问题更费解和棘手，我一般称这类人为“挖坑专家”。

2.2.3、如何选择？

  1. 我们在开发阶段，可以将公用库的版本设置为快照版本，而被依赖组件则引用快照版本进行开发，在公用库的快照版本更新后，我们也不需要修改pom文件提示版本号来下载新的版本，直接mvn执行相关编译、打包命令即可重新下载最新的快照库了，从而也方便了我们进行开发。
  2. 当开发进入预发布阶段，为了生产环境的稳定性，依赖应该是RELEASE版本，因为此时SNAPSHOT版本的模块自动获取新特性的特点恰恰会造成生产环境的不稳定性，生产环境上，稳定性重于一切。

2.2.4、maven插件versions

（1）背景：

现在已经很明确了，在开发期间，活跃模块的版本号使用SNAPSHOT，在生产期间，依赖RELEASE版本模块。貌似，我们找到了银弹，不过这个只是理想状态，即所有的模块的版本都在自己的掌控或者间接掌控下，只有这样你才能影响对应模块的版本号。往往是理想很丰满，现实却很骨感，如果你依赖的一个模块只有SNAPSHOT版本，并且该模块也很活跃，最无助的是模块的维护人不理会你的请求，那么是否就没辙了，只能把应用构建在不稳定模块上呢？

（2）插件介绍：

versions，这是一个非常强大的版本管理插件，其中有个对依赖版本加锁的特性——lock-snapshots，并且提供了参数可以控制锁定的依赖，就可以实现对特定的SNAPSHOT模块锁定版本，执行的命令如下：mvn versions:lock-snapshots -DincludesList="groupId:artifactId:type:classifier:version"，执行这个命令之后，对应的版本号会变化，比如1.0.0-SNAPSHOT会变成1.0.0.20090327.172306-4，即完成了锁定，此时这个SNAPSHOT就变成了固定小版本的稳定版本，不会在变化了，也相当于正式版的功能了。当然以后也可以解锁，详细请看对应文档。

avatar
文章
阅读
粉丝