Java架构师升级必备—Maven的版本发布

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

1. RELEASE的说明

1.1 snapshot与release的区别
大多数java开发的小伙伴都用过maven来对包进行管理。在本身写项目的过程当中，对本身的项目也会进行groupdId，artifactId,version的配置。下面咱们来对着3个配置进行简单说明。
1.groupId:顾名思义，这个里面包含的是本项目属于哪个group（即组织或公司）。通常咱们会用公司或者本身的前几级包名来进行定义。
2.artifactId:这个值定义的是本项目的名字。
3.version:这个就是咱们今天讲解的关键了。这个项目在maven进行发布之后的版本号。
通常，咱们在刚开一个项目之后会将version定义为1.0-SNAPSHOT。snapshot单词从字面意思来讲，是快照、照相的意思。为何咱们新的项目要使用SNAPSHOT呢？而不是咱们引入的那些公共包的.RELEASE或者只有版本号什么都不带呢？这两个又有什么区别呢？听我慢慢道来： 一个项目在未上线发布以前会在测试环境或者开发环境中进行测试和调整，也有可能有需求变动和重构。因此，snapshot说明了，这个包还未固化其自身提供的服务。在使用带有snapshot的包的时候要特别当心。他极可能发生变化，不知道何时你以前使用的功能就会被这个包的维护人员干掉或者改变了。 而你们使用的相似Spring之类的公共开源包都是以RELEASE结尾的，这说明了当前这个版本号的包会稳定的提供功能服务，不会发生任何变化。若是须要变化只能经过修改版本号。
1.2 release的必要性
当咱们的项目达到了当前的目标，在通过检测后不须要改变。这时咱们就须要将SNAPSHOT版本打包成RELEASE版本。只有这样，使用这个包的用户才能放心的将这个版本的包放入本身的项目中使用。而且，不会担忧这个功能包提供的功能会随时发生改变。 接下来咱们就学习如何将在git中管理的功能包从snapshot打包成为release版本

1. scm的配置

scm是mvn为咱们提供的，对版本管理软件进行管理和操做的插件。因为本指南只讲解打包过程，不会详细讲解本工具的具体概念和使用方式。
1.<project>
2.<scm>

1. <!--release包须要放入的nexus或者其余maven release包的仓库url地址-->
2. <url>http://xxxx/nexus/content/rep...;/url>
3. <!--connection, developerConnection: 都是链接字符串，其中后者是具备write权限的scm链接 -->
4. <!--须要打包项目的git地址-->
5. <developerConnection>scm:git:http://xxxx/c-h5/portal-commo...;/developerConnection>
6. <!--须要打包项目的git地址-->
7. <connection>scm:git:http://xxx/c-h5/portal-common...;/connection>
8. <!---->
9. <tag>HEAD</tag>
10. </scm>

13.</project>
3.maven-release-plugin的配置
1.<build>

1. <plugins>
2. <!-- 发布插件 -->
3. <plugin>
4. <groupId>org.apache.maven.plugins</groupId>
5. <artifactId>maven-release-plugin</artifactId>
6. <version>2.5.3</version>
7. <configuration>
8. <!--git用户名-->
9. <username>xxxxx@shishike.com</username>
10. <!--git密码-->
11. <password>xxxx</password>
12. <!--mvn目标指令-->
13. <goals>-f pom.xml deploy</goals>
14. </configuration>
15. </plugin>
16. </plugins>

18.</build>
4.release的操做流程
4.1 第一步release:prepare
这条命令主要是作打包前的准备。
1.输入对应的release须要打包的版本等信息，若是不输入有默认的内容
2.将须要记录和准备的内容缓存到pom.xml目录下的release.properties文件中
3.在本地和远程库的GIT中打上对应版本的tag
在准备过程当中还会run 单元测试等phase，若是没有异常的话能够继续最后一步。若是git尚未commit或单元测试失败会致使prepare失败，这时候你就须要到下面一个命令了。
4.2 后悔药release:rollback
若是在准备阶段发生错误，或者须要修改某些地方的话。就须要到这个命令了，这个命令执行之后会作如下这些事
1.删除线上git库tag，可是本地库tag没有被删除，须要手动使用git tag -d XXX进行删除。若是不将本地库中的tag删除将会致使prepare失败。
2.删除以前缓存在pom.xml统一目录下的配置
4.3 最后一步release:perform
若是确认无误了之后，就能够执行perform命令了。这个命令干了如下这些事：
1.验证代码合法性
2.将你以前的1.0-SNAPSHOT改成1.1-SNAPSHOT
3.将1.0版本deploy至scm配置的nexus release库中
4.将代码source。jar版本 javacode。jar打包上传至nexus库
恭喜，你已经把你的1.0-SNAPSHOT成功的打包成1.0的release版本了。同时你会发现你的pom.xml文件会自动的变成1.1-SNAPSHOT版本。虽然这一系列操做均可以经过手动完成。可是有这个工具的存在，免去了不少步骤。也规范了流程，何乐而不为呢。

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