以前在github发开源项目，都因为懒，从来不构建到中央仓库。最近因为其他人要用，联系我。希望可以发到中央仓库。我想，不就是mvn deploy嘛，开搞。一圈弄下来，发现真没那么简单。当中遇到了无数的坑，让我每一次都心里默默念到，发个项目，为何如此痛苦。
现将痛苦的过程详细记录下来。希望可以帮助到其他小伙伴少踩点坑。
首先，你需要到sonatype这个站点上去注册一个账号。这个页面长这个样子：
我当时以为我进错地方了，这不是jira吗。好吧。看url还是提issue的地方，这和发布项目有毛的关系…
好吧，点新建，项目选Community Support - Open Source，问题类型选New Project
填就是了。注意的是Group Id这里要填你自己的拥有的域名，比如com.xxxx，没有的话，自己去注册域名去。填好之后就是等待审核。我搜了下，网上小伙伴说要等待3，5天。
3个小时后，我上去再去看，管理员给我回复了：
大致意思就是要你证明这个域名是属于你自己的。有2种方法，加一个txt类型的解析到你的域名里是最快的方法。
我的域名申请在腾讯云。登陆进去。找到域名解析设置。加进去txt类型的解析。主机记录填那个jira ticket名字，记录值是你这个ticket的链接url。
设置完了后，去回复管理员。然后继续等待。
管理员大概很快就回复了我。并通过了验证。接下来，就要捣鼓项目了。
2
要上传中央仓库，你的项目必须要符合一些规范才行。
首先pom文件是有要求的，在你的项目顶层pom文件里一定要有以下标签：
- name
- description
- url
- licenses
- developers
- issueManagement
- scm
照着一个个填，我参考了一个开源项目的pom，例子如下：
补全了pom的信息后，还需要补全一些maven插件，主要有：
- maven-source-plugin
- maven-site-plugin
- maven-javadoc-plugin
- maven-gpg-plugin
例子如下:
当然还需要加上distributionManagement
你的sonatype的用户名和密码当然不能写在项目pom里，你得在maven的setting.xml里添加server
3
补全了pom的一些规定信息和插件后。可以试下是否可以正确无误的生成javadoc，在项目根目录下运行
mvn site
接下去就是无尽的等待，等待从中央仓库下载各种插件。这里最好搭个梯子翻墙，速度会快点。我全程用梯子，也等了40分钟，这时候可以去干点别的事情。。40分钟后，终于build成功了：
接下去就是签名了。想要上传到仓库，jar包必须被正确签名。
用gpg来进行签名，网上搜了下，windows的用户可下载gpg4win，我这里用的是mac，不能用这个软件。只能自己安装个命令行gpg工具了
brew install gpg
安装成功后，执行命令生成秘钥对：
gpg —gen-key
根据提示，填写用户名和邮件地址。然后确认。
我mac上用的是iterm2，确认后一直卡着，提示正在生成字节。然后等了很久也没有反应。我一直以为这就是正常现象，已经生成秘钥对了。只不过命令行不友好，没有告诉我。。。导致了我后面签名一直签不成功。
后来我换了一个ssh工具，electerm，才正确生成。最后是要让你输入passphase。以下是正确生成秘钥对的界面
接下去就是要利用maven-gpg-plugin对jar包进行签名了。在进行之前，需要在setting.xml文件的当前profile里加上
然后运行mvn install。
我这里一直签名不成功，报以下错：
网上搜索了下，原来是我本地的gpg工具版本太新了，和maven的插件版本不匹配。需要在~/.gnupg这个目录下增加2个配置：
gpg.conf
use-agent
pinentry-mode loopback
gpg-agent.conf
allow-loopback-pinentry
折腾了半天，终于可以mvn install正确执行gpg的jar包签名了。接下去准备进行激动人心的mvn deploy了。
由于之前已经解决了jar包签名的问题，deploy过程也是相当的顺利。deploy过程中，会把你项目的jar包，加签信息，javadoc，javasource等包一并上传到sonatype服务器。
deploy好，你就可以在sonatype的staging repo里看到了，staging repo相当于暂存的状态，还没有正式发布到release仓库，sonatype需要校验你上传jar包的规范性，合法性。
选中你提交的暂存信息，点close，等一段时间，refresh之后底下会有校验结果。全部通过后才能点release。底下是我第一次校验的结果：
可以看到，有2项没通过，第1项是我pom不规范，原因是我第一次pom提交的时候少了
gpg生成的是RSA的key，有公钥和私钥。我本地加签之后，应该把公钥给到sonatype，否则sonatype无法验证我的jar包的加签信息是否有效。所以我之前流程应该缺少了这一步！
看详细信息，sonatype应该是到以下3个地方去拿key，发现都没有，所以才报了错。
http://pgp.mit.edu:11371
http://keyserver.ubuntu.com:11371
http://pool.sks-keyservers.net:11371
所以我们只需要上传key到任意一个key server就可以了。
gpg上传公钥的命令是
gpg —keyserver hkp://keyserver.ubuntu.com:11371 —send-keys yourkeyid
这里我踩了2个坑，第一个是上传的协议是hkp，不是http，网上一搜才知道。sonatype报错的地方都是http。
第二个是gpg在发送公钥的时候并不是直接指定公钥发上去，而是需要你的keyid，个人推测可能是根据这个keyid再在文件系统中找到公钥进行发送吧。它需要什么，我们只能给什么。问题是这个keyId是什么呢，从哪来呢
在生成秘钥对的时候，我注意到给了一个fingerprint，也能用gpg —list-keys 这个命令进行查看：
难道这个就是keyId？我尝试着用这个作为keyId，进行发送，也能成功。但是在sonatype上进行检测却过不了。
这个keyId卡了我很久，最后还是依靠万能的谷歌查到了。原来所谓的KeyId就是fingerprint的后16个字符。我Fxx…(省略N个赞美的词语)。
拿到了正确的KeyId，继续执行gpg的上传命令，上传好，然后运行查看key的命令：
gpg —keyserver hkp://keyserver.ubuntu.com:11371 —recv-keys yourkeyid
4
我们继续在sonatype的staging repo进行close操作校验，这个操作其实我已经做了n遍了，各种坑，所以见到以下这个画面的时候有点激动：
可以看到，所有的校验都通过了，没有报错了。Release的按钮也已经点亮。通往中央仓库的大门已经敞开！
坚定的点下release按钮。输入备注后，成功提交。
在sonatype进行Release后 ，要真正在中央仓库看到，可能要等上个5到6小时。
最后。终于，在中央仓库的地址我看到了提交的包，大功告成
原本以为提交中央仓库可能不是那么困难，实际操作一遍，发现需要注意的细节有很多。而项目本身也有很多需要规范的地方。整个过程花了一天时间，碰了无数的坑，我工位旁边的小伙伴之前操作过，但是时间久远，细节又很多。所以对很多坑印象比较模糊了。所以记录下来。
个人开发的项目被其他人所使用，是一件很有成就感的事情。所以提交中央仓库是必然途径。虽然我希望整个过程能简单点，但是中央仓库就一个，只能按照它的规范来做。希望有人看到这篇记录，能让你少走点弯路~
若有收获，就点个赞吧
0 人点赞
