VasDolly 插件的本地发布

前文有提到,想把修改后的 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 GnuPGwinget install GnuPG.Gpg4win,然后(新开命令提示符窗口)执行 gpg --full-generate-key 生成了一对公私钥匙对,并用 gpg --export-secret-keys -a "you@email.com" > private-key.asc 命令把密钥导出。

maven.gradle 文件中,需要提供的信息有三个,signing.secretKeyRingFilesigning.keyIdsigning.password。在生成过程中没有看到 key ID 相关信息,又问了一下 AI,它说 gpg --list-secret-keys --keyid-format LONG 的输出(示例见下

)中,secssb 后一列里,紧随表示密钥和类型的信息的(也即 / 字符后的部分)就是 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

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注