maven版本管理

现在所说的maven版本不同于SVN的版本控制哦！！！

之前我们说过Maven的版本分为快照和稳定版本，快照版本使用在开发的过程中，方便于团队内部交流学习。而所说的稳定版本，理想状态下是项目到了某个比较稳定的状态，这个稳定包含了源代码和构建都要稳定。

一、如何衡量项目的稳定状态呢？

1. 所有的自动化测试应当全部通过

2. 项目没有配置任何快照版本的依赖

3. 项目没有配置任何快照版本的插件

4. 项目所包含的代码都已经全部提交到了版本控制系统中

5.我们应当再一次执行Maven构建，以确保项目的状态是OK的

6. 我们将这一次变更提交到版本控制的主干中，并打上标签

只有满足了上述6个条件, 我们就可以将这一个快照版本更新至发布版本

 

二、在开发的过程中，版本号要如何进行变更呢？Maven是否有潜在的约定？

 

我们在开发的过程中，下载jar包的时候经常会发现某个jar类似这样：1.2.3-beat-4.jar

多么复杂的一个名称。。。下面来解释一下，这里每个数字的含义：

“ 1 ” :  表示该版本的第一个重大版本

“ 2 ” :  表示这是基于重大版本的第二个次要版本

“ 3 ” :  表示该次要版本的第三个增量

" beat-4" : 表示该增量的一个里程碑

用一个图来描述：

< 主版本 >  ------   < 次版本 > ------ < 增量版本 > ------ < 里程碑版本 >

主版本：表示了项目的重大架构变更  struts1 --  struts2

次版本：表示较大范围的功能增加和变化  Nexus1.5 ----   Nexus1.4

增量版本：一般表示重大Bug修复  

里程碑版本：指某一个版本的里程碑   *.*-alpha-1  *.*-beat-1

看起来有点麻烦啊， 但是在一般来说，我们只会声明主版本和次版本，增量版本和里程碑版本就不一定了。

注：maven中约定的版本次序：

对于主版本、次版本、增量版本来说他们的比较是基于数字的，因此：1.5>1.4>1.3>1.2.11>1.2.8

对于里程碑版本来说，比较是基于字符串的，因此：1.5>1.4>1.3>1.2.3>1.2.11

 

三、主干、分支、标签

上面的笔记中提到了主干和标签，到底如何理解主干、分支、标签呢？

主干: 项目开发代码的主体，是从项目开始到当前都处于活动的状态，从这里可以获得项目最新的源代码和几乎所有的变更历史

分支: 从主干的某个点分离出来的代码拷贝，通常可以在不影响主干的前提下，在这里进行重大的bug修复或者实验性质的开发，如果达到了预期的目的，通常将这里的变更合并到主干中去。

标签: 用来标识主干或者分支的某个点的状态，以代表项目的某个稳定状态，也就是通常说的发布状态

这三个元素，可以清晰的描述出项目的版本管理，而且也已经成了一个默认的行业标准。

 

四、自动化版本发布

用久了手动版本发布之后，我们会想到能否进行自动化的发布版本，答案是肯定的，这将引入一个新的插件：Maven Release Plugin

通过一些必要的配置，就可以完成版本发布

Maven Release Plugin 插件简介：

该插件主要有三个目标：release: prepare,  release: rollback,  release: perform (什么是插件目标)，在介绍分支自动化的时候还会引入branch目标

①release:prepare   准备版本发布，依次执行下列操作

1. 检查项目是否有未提交的代码

2. 检查项目是否有快照版本依赖

3. 根据用户的输入将快照版本升级为发布版

4. 将POM中的SCM信息更新为标签地址

5. 基于修改后的POM执行maven构建

6. 提交POM变更

7. 基于用户输入为代码打标签

8. 将代码从发布版升级为新的快照版

9.提交POM变更

release: rollback

回退release: prepare所执行的操作。将POM回退至release:prepare之前的状态，并提交。

注：该步骤不会删除release:prepare生成的标签，需要用户手动删除

release: perform

执行版本发布

签出release:prepare生成的标签中的源代码，并在此基础上执行mvn deploy命令打包并部署构件至仓库

 

注：要为项目发布版本，首先需要为其添加正确的版本控制系统信息(这是因为Maven Release Plugin需要知道版本控制系统的主干、标签等地址后才能执行相关操作)

 

②分支的自动化创建

先看一下Maven Release Plugin 的branch目标能帮助我们做哪些事情

1. 检查本地有无未提交的代码

2. 将分支更改POM的版本，如：1.1.0-SNAPSHOT改成1.1.1-SNAPSHOT

3. 将POM中的SCM信息更新为分支地址

4. 提交以上更改

5. 将主干代码复制到分支中

6. 修改本地代码使其回退到分支前的版本(用户可以指定新的版本)

7. 提交本地更改

注：此时也必须正确的配置SCM信息

 

五、代码安全

代码安全是我们比较关心的一个问题， 比如说，当我们从中央仓库下载第三方构件的时候，我们可能要去验证这些文件的合法性，或者当我们发布项目后，使用我们项目的人也要验证

引入一个新的插件：Maven GPG Plugin 自动的完成签名

在使用Maven GPG Plugin之前，首先需要确定GPG是可用的，然后再POM中配置插件即可

pom.xml

 

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-gpg-plugin</artifactId>
    <version>1.0</version>
    <executions>
         <execution>
        <id>sign-artifacts</id>
        <phase>verify</phase>
        <goals>
              <goal>sign</goal>
        </goals>
         </execution>
    </executions>
</plugin>

然后使用一般的Maven命令签名并发布项目构件

 

 

$mvn clean deploy -Dgpg.passphrase=****

注：

 

1. 如果不提供 -Dgpg.passphrase参数，运行时就会要求输入密码