从老Scala(sbt)项目转向Java开发的架构方案咨询

场景描述 #

我接手了一个老旧Scala应用，核心目标是用Java编写新功能，但需要复用原有公共代码。当前仓库结构如下：

├──common-scala-module-1
│   ├── src
│   │   ├── scala
│   │   │   ├── **/*.scala
│   │   ├── test
│   │   │   ├── **/*.scala
├──common-scala-module-2
│   ├── src
│   │   ├── scala
│   │   │   ├── **/*.scala
│   │   ├── test
│   │   │   ├── **/*.scala
├──scala-module-3
│   ├── src
│   │   ├── scala
│   │   │   ├── **/*.scala
│   │   ├── test
│   │   │   ├── **/*.scala
├──scala-module-4
│   ├── src
│   │   ├── scala
│   │   │   ├── **/*.scala
│   │   ├── test
│   │   │   ├── **/*.scala
├── build.sbt
├── .gitignore
└── (other scala files that doesn't matter for this problem)

四个模块均生成Jar包，其中生产核心模块为scala-module-3和scala-module-4（依赖两个公共模块）。后续我将用Java开发新模块，但仍需维护旧代码，现寻求以下架构建议：

1. 是否应保留原有仓库，新建仓库存放Java模块？（我认为拆分更合理，可将公共模块Jar作为依赖引入Java代码，原有仓库仅作维护）
2. 是否应从SBT迁移至Gradle/Maven？若迁移选哪个？答案是否受第一个问题的决策影响？（我熟悉Maven和Gradle，倾向选Maven，且对SBT了解较少）

注：我具备丰富Java开发经验，了解Scala基础，希望明确各方案的利弊以简化后续维护。

一、仓库拆分 vs 单仓库维护 #

拆分仓库的优势 #

• 职责清晰：原有Scala仓库专注旧代码维护，Java新仓库专注新功能开发，团队成员明确各自维护范围，避免跨语言混编的认知负担。
• 依赖解耦：公共Scala模块发布为Jar包引入Java项目，明确依赖边界，减少新代码对旧Scala代码的直接修改需求，降低旧代码变更影响新功能的风险。
• 工具链适配：Java项目可完全使用熟悉的Maven/Gradle工具链，无需适配SBT，简化新模块的构建、测试和部署流程。
• 权限管控：可针对两个仓库设置不同权限，比如旧仓库仅开放维护权限，新仓库开放开发权限，避免误操作影响生产核心的Scala模块。

拆分仓库的劣势 #

• 依赖发布成本：每次公共Scala模块更新，需重新发布Jar包到私有仓库，再在Java项目中更新依赖版本，增加版本管理步骤。
• 跨仓库调试麻烦：若需同时修改公共Scala模块和Java新模块，需搭建多仓库本地调试环境，比单仓库内调试繁琐。
• 版本一致性风险：若公共模块版本管理不当，可能出现Java项目依赖版本与生产环境Scala模块版本不一致的问题，引发兼容性故障。

单仓库维护的优势 #

• 调试便捷：修改公共Scala模块后可直接在Java模块中测试，无需发布依赖，适合频繁跨语言协作的场景。
• 版本统一：所有模块使用同一套版本号，避免依赖版本不一致问题，便于整体发布和回滚。

单仓库维护的劣势 #

• 工具链冲突：需在同一仓库兼容SBT和Maven/Gradle，构建配置会复杂化，增加维护成本。
• 代码复杂度上升：跨语言代码混编在一个仓库，会让新开发者难以快速理解项目结构，增加上手成本。
• 构建效率下降：单仓库构建时会同时编译Scala和Java代码，模块较多时构建时间变长。

结论：如果后续新功能与旧Scala代码交互较少，仅依赖公共模块的稳定功能，拆分仓库是更优选择，能最大化简化维护成本；如果需要频繁修改公共模块配合新功能开发，短期可考虑单仓库，长期仍建议拆分。

二、构建工具迁移选择及与仓库决策的关联 #

是否迁移？ #

• 若选择拆分仓库：原有Scala仓库可继续保留SBT，仅需维护旧代码，无需学习新工具，降低旧代码维护成本；Java新仓库直接使用你熟悉的Maven/Gradle，完全适配技术栈。这种情况下，迁移原有仓库的构建工具不是必须的，除非旧SBT配置本身存在严重问题（如依赖管理混乱、构建速度极慢）。
• 若选择单仓库维护：必须统一构建工具，否则会面临多工具配置的复杂度问题。此时建议迁移到Gradle或Maven，利用你熟悉的技术栈降低整体维护成本。

Gradle vs Maven选择 #

• Maven：
  • 优势：约定大于配置，结构清晰，你熟悉其生态和配置方式，Java开发者更容易上手；依赖管理稳定，适合需要严格规范的项目。
  • 劣势：灵活性不如Gradle，Scala和Java混合项目的配置虽支持但不够简洁；构建速度相对较慢。
• Gradle：
  • 优势：支持增量构建，速度更快；DSL更灵活，能更好处理Scala和Java混合项目的构建；扩展性强，适合复杂构建需求。
  • 劣势：学习曲线比Maven稍陡，若团队其他成员不熟悉，会增加培训成本。

结论：结合你熟悉Maven的情况，若迁移优先选Maven。拆分仓库时，原有Scala仓库无需迁移；单仓库维护时，必须迁移到Maven或Gradle，优先选Maven简化维护工作。

内容的提问来源于stack exchange，提问作者GoMati