前文有提到,想把修改后的 VasDolly 插件无论如何也应该是骡子是马拉出来遛遛,这就得能把它发布出来——至少在本地。
查看 VasDolly 项目中的 plugin 模块的 build.gradle
,里面是有对上级目录中的 maven.gradle
的引用的,打开后者一看,果然里面就有 publishing 和 signing 对应的配置块。既然有,可是为什么 gradle 任务列表里面看不到任何与打包发布相关的任务呢?困扰许久以后,终于注意到 Gradle 任务视图的上方有个小提示图标,点开看其信息,大意是指为了提速,Gradle 在 sync 的过程中,默认并没有完全把所有任务 configure 完成,如果要改变这一行为,要到 Settings 里,找到 Experimental 标签页里的 Configure all Gradle tasks during Gradle Sync (this can make Gradle Sync slower) 的选项并启用之。此后再 Gradle sync 一次,果然出现了 publish[XXX]ToMavenLocal 的任务。
双击该任务执行,不出所料失败了。自己就知道,毕竟 VasDolly 的作者不至于愚到会把签名信息也开源出来。在 maven.gradle
文件的开头,就有从 local.properties
文件里读取三个签名有关的信息的操作,显然,自己打开 local.properties
把那三个信息补全应该是正道。首先想到的就是把自己素日里使用的 app 开发用的 jks 文件复用过来,但是会报出这样的错误信息,
> Error while evaluating property ‘signatory’ of task ‘:plugin:signVasdollyReleasePublication’
> Unable to read secret key from file: X:\dev.jks (it may not be a PGP secret key ring)
问了一下 AI,回答说 jks 不能用于此处,需要用 GPG 工具。于是先后执行了 winget search GnuPG
和 winget install GnuPG.Gpg4win
,然后(新开命令提示符窗口)执行 gpg --full-generate-key
生成了一对公私钥匙对,并用 gpg --export-secret-keys -a "you@email.com" > private-key.asc
命令把密钥导出。
在 maven.gradle
文件中,需要提供的信息有三个,signing.secretKeyRingFile
、signing.keyId
、signing.password
。在生成过程中没有看到 key ID 相关信息,又问了一下 AI,它说 gpg --list-secret-keys --keyid-format LONG
的输出(示例见下
)中,sec
和 ssb
后一列里,紧随表示密钥和类型的信息的(也即 /
字符后的部分)就是 key ID,其中 sec
的对应主 ID,ssb
对应子 ID。于是把这三个信息一个萝卜一个坑填写完整,兴冲冲地执行发布任务,失败。错误没什么变化,注意到了最后一行是
Cause: invalid header encountered
根据经验,似乎文件格式就有问题。接下来是误入歧途时间,老夫又是更改该文件里的回车换行,在 DOS/Windows 和 Unix 惯例之间切换,又是删除其中不必要的空行,都无功而返。再问 AI,它说你应该在构建脚本里写清楚 useGpgCmd() // 确保使用 GPG 命令行工具
,老夫照做之后,问题走到了另一个一看就是偏差更大的方向,赶紧退了回来。既然 AI 不给力,只好又放狗看一圈有没什么蛛丝马迹,果然被一篇博客里的配图触发了新疑点,博主强调要把导出的密钥文件扩展名强行指定为 gpg
(或者 pgp
)。
三太爷的第一反应是,恐怕 GnuPG 在本地的某个地方保存着 gpg 格式的文件,需要指向它才对。问 AI 具体路径,它答复是用户目录下的 .gnupg
目录,但此目录并不存在。再追下去,发现其实在用户目录下的 AppData\Roaming\gnupg
下,确实有一个名为 trustdb.gpg
的 gpg 文件。但是使用它作为 secretKeyRingFile 仍然出错。再一考虑,这个文件应该是个 key 的仓库,要指定的文件显然应该是仅包含所需的单个 key 的文件才对,路子还是走歪了。于是回过头来,审视导出密钥的命令行,发现其中的 -a
参数,其实是 --armor
的缩写,其含义是导出文本格式的密钥,而不是想当然的“all”的含义。于是重新导出密钥,将 -a
参数去掉,文件扩展名改成 .gpg
。导出成功后相应把前述的三个信息更新,再执行 publish 任务,有进展了,报 key ID 有误。看了一眼,原来是它需要短格式的 ID,仅有八个字符的长度,而三太爷填的是用 gpg --list-secret-keys --keyid-format LONG
命令查看到的 ID,长度是所需的两倍之多。于是把 LONG 改为 SHORT 后看,ID 果然变短(即是长 ID 的后一半),又更新了 signing.keyId
之后再次 publish,大功告成。
到用户目录下的 .m2\repository
目录里一看,VasDolly 的 plugin 相关内容已经就位。今日时间有限,就先不测试它的功能了,容后再叙。
远程发布可以参考:https://blog.csdn.net/csdn_lqr/article/details/115979598