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


org.apache.maven.plugins
maven-gpg-plugin
1.0


sign-artifacts
verify

sign



然后使用一般的Maven命令签名并公布项目构件
$mvn clean deploy -Dgpg.passphrase=**

注:
1. 假设不提供 -Dgpg.passphrase參数,执行时就会要求输入password

本文同意转载,但请标明出处:http://blog.csdn.net/wanghantong/article/38424065,
版权全部

你可能感兴趣的:(随笔,maven,管理)