私は Scala に飛び込んでいて、sbt に気付きました。私は Java/groovy プロジェクトで Gradle に非常に満足しており、Gradle 用の scala プラグインがあることも知っています。
Scala プロジェクトで Gradle よりも sbt を好む正当な理由は何でしょうか?
SBT と Gradle の主な違いの 1 つは、依存関係の管理です。
キャッシュが混乱する可能性があるのは事実ですが、Ivy がスナップショットの解決を理解していないというのは事実ではありません。Eugene はこの点を別のスレッド (おそらく管理者リスト) で説明しました。0.12 で対処された sbt の自動更新に問題があります。
私の知る限り、Ivy がサポートしていないのは、Maven が行う方法でスナップショットを公開することです。これについては別の場所で述べたと思いますが、誰かが状況を改善したい場合は、依存関係管理コードを再利用するために Gradle チームと協力するのが最善であるというのが私の意見です。
Ivy と Maven スナップショットの依存関係の問題は、Gradle が最終的に Ivy を独自の依存関係管理コードに置き換えた理由の 1 つです。それは大きな仕事でしたが、私たちに多くの恩恵をもたらしました。
このツイートは、すべての状況が将来進化する可能性があると述べています。
Mark は以前、SBT に Ivy の代わりに Gradle を使用することに関心があると述べていました。
(両方のツールは互いに学習できます)
私にとって SBT の主な機能は次のとおりです。
fsc
)。~test
は、変更を保存するたびにプロジェクトを再コンパイルしてテストします。欠点は次のとおりです。
sbt は Scala DSL であり、Scala は第一級市民であるため、原理的には Scala が適しているようです。
しかし、sbt はバージョン間で大きな互換性のない変更が行われているため、タスクに対して適切に機能するプラグインを見つけて機能させることが難しくなっています。
私は個人的に sbt を断念しました。なぜなら、sbt は解決するよりも多くの問題を引き起こしていたからです。私は実際にgradleに切り替えました。
図に行きます。
私は gradle にかなり慣れていませんが、sbt にも非常に慣れていません。これまでのところ、sbt で本当に気に入っているのは、対話型のコンソールです。「検査」などのコマンドを使用して、何が起こっているのかをよりよく理解することができます。AFAIK gradle は、この atm のようなものを提供していません。
Sbt と gradle はどちらも静的に型付けされた言語に基づいていますが、sbt にはいくつかの利点があります。