Java架构师必备知识-Maven的版本发布

今天动力节点Java学院给大家带来Java架构师必学知识点，Maven的版本发布。

1. RELEASE的说明

1.1 snapshot与release的区别

大多数java开发的小伙伴都用过maven来对包进行管理。在自己写项目的过程中，对自己的项目也会进行groupdId，artifactId,version的配置。下面我们来对着3个配置进行简单说明。

[if !supportLists]1. [endif]groupId:顾名思义，这个里面包含的是本项目属于哪一个group（即组织或公司）。一般我们会用公司或者自己的前几级包名来进行定义。

[if !supportLists]2. [endif]artifactId:这个值定义的是本项目的名字。

[if !supportLists]3. [endif]version:这个就是我们今天讲解的关键了。这个项目在maven进行发布以后的版本号。

一般，我们在刚开一个项目以后会将version定义为1.0-SNAPSHOT。snapshot单词从字面意思来说，是快照、照相的意思。为什么我们新的项目要使用SNAPSHOT呢？而不是我们引入的那些公共包的.RELEASE或者只有版本号什么都不带呢？这两个又有什么区别呢？听我慢慢道来： 一个项目在未上线发布之前会在测试环境或者开发环境中进行测试和调整，也有可能有需求变更和重构。所以，snapshot说明了，这个包还未固化其自身提供的服务。在使用带有snapshot的包的时候要特别小心。他很可能发生变化，不知道什么时候你之前使用的功能就会被这个包的维护人员干掉或者改变了。 而大家使用的类似Spring之类的公共开源包都是以RELEASE结尾的，这说明了当前这个版本号的包会稳定的提供功能服务，不会发生任何变化。如果需要变化只能通过修改版本号。

1.2 release的必要性

当我们的项目达到了当前的目标，在经过检测后不需要改变。这时我们就需要将SNAPSHOT版本打包成RELEASE版本。只有这样，使用这个包的用户才能放心的将这个版本的包放入自己的项目中使用。并且，不会担心这个功能包提供的功能会随时发生改变。 接下来我们就学习如何将在git中管理的功能包从snapshot打包成为release版本

2. scm的配置

scm是mvn为我们提供的，对版本管理软件进行管理和操作的插件。由于本指南只讲解打包过程，不会详细讲解本工具的具体概念和使用方式。

1. <project>

2. <scm> 

3.         <!--release包需要放入的nexus或者其他maven release包的仓库url地址-->

4.        <url>http://xxxx/nexus/content/repositories/releases/</url>

5.         <!--connection, developerConnection: 都是连接字符串，其中后者是具有write权限的scm连接 -->

6.         <!--需要打包项目的git地址-->

7.         <developerConnection>scm:git:http://xxxx/c-h5/portal-common-base.git</developerConnection>

8.         <!--需要打包项目的git地址-->

9.        <connection>scm:git:http://xxx/c-h5/portal-common-base.git</connection>

10.         <!---->

11.         <tag>HEAD</tag>

12.    </scm>

13. </project>

3.maven-release-plugin的配置

1. <build>

2.  <plugins>

3.             <!-- 发布插件 -->

4.            <plugin>

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

6.                <artifactId>maven-release-plugin</artifactId>

7.                <version>2.5.3</version>

8.                 <configuration>

9.                     <!--git用户名-->

10.                     <username>xxxxx@shishike.com</username>

11.                    <!--git密码-->

12.                    <password>xxxx</password>

13.                     <!--mvn目标指令-->

14.                     <goals>-f pom.xml deploy</goals>

15.                 </configuration>

16.             </plugin>

17.        </plugins>

18. </build>        

4.release的操作流程

4.1第一步release:prepare

这条命令主要是做打包前的准备。

1. [endif]输入对应的release需要打包的版本等信息，如果不输入有默认的内容

2. [endif]将需要记录和准备的内容缓存到pom.xml目录下的release.properties文件中

3. [endif]在本地和远程库的GIT中打上对应版本的tag

在准备过程中还会run 单元测试等phase，如果没有异常的话可以继续最后一步。如果git还没有commit或单元测试失败会导致prepare失败，这时候你就需要到下面一个命令了。

4.2后悔药release:rollback

如果在准备阶段发生错误，或者需要修改某些地方的话。就需要到这个命令了，这个命令执行以后会做以下这些事

1. [endif]删除线上git库tag，但是本地库tag没有被删除，需要手动使用git tag -d XXX进行删除。如果不将本地库中的tag删除将会导致prepare失败。

2. [endif]删除之前缓存在pom.xml统一目录下的配置

4.3最后一步release:perform

如果确认无误了以后，就可以执行perform命令了。这个命令干了以下这些事：

1. [endif]验证代码合法性

2. [endif]将你之前的1.0-SNAPSHOT改为1.1-SNAPSHOT

3. [endif]将1.0版本deploy至scm配置的nexus release库中

4. [endif]将代码source。jar版本 javacode。jar打包上传至nexus库

恭喜，你已经把你的1.0-SNAPSHOT成功的打包成1.0的release版本了。同时你会发现你的pom.xml文件会自动的变成1.1-SNAPSHOT版本。虽然这一系列操作都可以通过手动完成。但是有这个工具的存在，免去了很多步骤。也规范了流程，何乐而不为呢。

.动力节点Java架构师班深度剖析Java底层原理，热门技术深入探讨，前沿技术深入解读，大项目实战重构，从0到1做架构，从全局思维出发，带你把控大型项目中别人忽略的重要细节节点，站在巨人肩膀上学习架构师，带你领会架构师不一样的视野