KuzuDB迁移Maven Central发布渠道的技术实践

随着Sonatype宣布将在2025年6月30日终止对OSSRH（OSS Repository Hosting）服务的支持，所有依赖Maven Central进行软件分发的开源项目都面临着发布渠道迁移的挑战。本文以KuzuDB项目为例，深入探讨从传统OSSRH迁移到Central Publisher Portal的技术方案与实践经验。

背景与挑战

Maven Central作为Java生态中最核心的依赖仓库，其发布流程的变更直接影响着所有基于JVM语言开发的项目。传统OSSRH服务提供了成熟的Gradle集成方案，而新推出的Central Publisher Portal在初期存在明显的工具链适配问题：

1. 对Gradle构建系统的官方支持缺失
2. 第三方发布工具（如JReleaser）功能不完善且侵入性强
3. 发布流程与现有持续集成体系难以兼容

技术方案选型

经过对Central Publisher Portal新特性的评估，我们发现其提供的Staging API与传统OSSRH API保持了高度兼容性。这为迁移工作提供了关键突破口：

核心迁移策略

1. 端点替换：仅需将发布目标地址从OSSRH切换到Portal的Staging API端点
2. 认证适配：沿用现有的Sonatype账户体系，但需要重新配置API令牌
3. 构建脚本改造：保持原有Gradle发布逻辑，仅调整发布配置块

Gradle配置示例

publishing {
    repositories {
        maven {
            url = "https://s01.oss.sonatype.org/service/local/staging/deploy/maven2/"
            credentials {
                username = project.findProperty("ossrhUsername")
                password = project.findProperty("ossrhPassword")
            }
        }
    }
}

实施要点

1. 兼容性验证：需在测试环境充分验证发布、暂存、发布的全流程
2. 双轨运行：建议在过渡期同时维护新旧两套发布配置
3. 文档更新：项目CONTRIBUTING文档需要同步更新发布指南

经验总结

1. 提前规划：避免在截止日期前集中迁移导致的系统拥塞
2. 工具链评估：对于复杂项目，建议先建立概念验证（PoC）
3. 监控机制：新增发布失败自动告警，确保第一时间发现问题

通过系统性的迁移方案，KuzuDB项目成功在截止日期前完成了发布渠道的平稳过渡。这一实践也为其他面临类似迁移需求的开源项目提供了可复用的技术路径。