Gradle驱动纯Scala项目compile依赖的合规替代方案

嘿，我太懂你这种升级Gradle后的纠结了——看着满屏的弃用警告，想换implementation又搞不定子项目间的传递依赖，找官方指引还偏偏没专门针对纯Scala项目的，简直头大。针对你的问题，我整理了最实用的解决方案和对各个备选方案的分析：

核心结论：用java-library插件+api配置是合规标准方案 #

你担心的“Scala项目用Java相关插件怪异”完全是多余的，这其实是当前Gradle纯Scala多项目的公认最优解。原因很简单：

• Gradle的Scala插件本身就继承自Java插件，而java-library插件是Java插件的功能扩展版，它不会给Scala项目引入任何Java专属冗余，只是新增了api这个用于传递依赖的配置项——刚好填补了implementation不传递的缺口。
• 这种组合完全符合Gradle的插件设计逻辑，社区里大量Scala项目都在这么用，虽然官方没单独写Scala的指引，但从插件依赖关系来看，这是完全合规的。

具体操作示例 #

在你的Scala子项目的build.gradle（或build.gradle.kts）中，只需要先应用java-library插件再应用Scala插件，然后替换依赖声明即可：

plugins {
    id 'java-library'
    id 'scala'
}

dependencies {
    // 子项目间需要让下游依赖可见的传递依赖 → 用api替换原来的compile
    api project(':common-utils')
    // 不需要传递的外部依赖 → 用implementation
    implementation 'org.scala-lang:scala-library:2.13.10'
    // 测试依赖用testImplementation替代testCompile
    testImplementation 'org.scalatest:scalatest_2.13:3.2.15'
}

对你列出的备选方案的分析 #

• 继续使用compile依赖：短期能凑活，但Gradle明确标记compile为弃用，后续版本肯定会彻底移除，到时候再大规模迁移成本更高，不推荐长期使用。
• 手动展开所有传递依赖：完全是给自己挖坑，不仅会让依赖图急剧膨胀，后续子项目依赖变更时，你还要手动同步所有相关项目的依赖声明，维护成本爆炸，绝对不要选。
• 应用java-library插件：这就是上面说的最优解，一点都不“不妥”——Gradle的插件体系就是为了组合使用设计的，Scala和Java插件的兼容性非常好，不会有任何实际危害。
• 自定义api依赖：完全没必要，Gradle已经通过java-library插件实现了这个功能，重复造轮子只会增加后续维护的风险，违背了使用插件的初衷。

关于官方指引的补充 #

确实，Gradle团队在纯Scala项目的依赖声明指引上有缺位，但从插件的设计逻辑和社区实践来看，java-library+Scala插件的组合是当前最稳妥的选择，不用担心合规性问题。

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