comparing sbt and Gradle [closed]

问题:

I am diving into Scala and noticed sbt. I have been quite happy with Gradle in java/groovy projects, and I know there's a scala plugin for Gradle.

What could be good reasons to favour sbt over Gradle in a Scala project?

回答1:

Note that one key difference between SBT and Gradle is its dependency management:

• SBT: Ivy, with a a revision which can be given as a fixed one (1.5.2, for instance) or as latest (or dynamic) one.
  See "Ivy Dependency"
  That means the "-SNAPSHOT" mechanism support can be problematic, even though Mark Harrah details in this thread:

It is true the cache can get confused, but it is not true that Ivy doesn't understand resolving snapshots. Eugene explained this point in another thread, perhaps on the admin list. There is an issue with sbt's auto-update that was addressed in 0.12.

What Ivy does not support, as far as I know, is publishing snapshots in the manner Maven does. I believe I have stated this elsewhere, but if anyone wants to improve the situation, my opinion is that effort is best spent working with the Gradle team to reuse their dependency management code.

• Gradle: This thread mentions (Peter Niederwieser):

Just to let you know, problems with Ivy and Maven snapshot dependencies were one of the reasons why Gradle eventually replaced Ivy with its own dependency management code. It was a big task, but brought us a lot of goodness.

This tweet mentions that the all situation could evolve in the future:

Mark said in the past that he was interested in using Gradle instead of Ivy for SBT.

(both tools can learn from each other)

回答2:

For me the key features of SBT are:

• Fast compilation (faster than fsc).
• Continuous compilation/testing: the command ~test will recompile and test you project everytime you save a modification.
• Cross-compilation and cross-publishing, across several scala versions.
• Automatically retrieving dependencies with the correct scala version compatibility.

The downsides are:

• A hieroglyphic syntax that tends to discourage new users (especially if they come from Java)
• No easy way to define a "task": if you need a special build procedure, you will need to either find a plugin, or write a plugin yourself.

回答3:

sbt is a Scala DSL and for it Scala is a first class citizen, so in principal it seems to be a good fit.

But sbt suffers from major incompatible changes between versions, which makes it hard to find the correct working plugin for a task and get it to work.

I personally gave up on sbt, since it was causing more problems than it solved. I actually switched to gradle.

Go figure.

回答4:

I'm fairly new to gradle, and very new to sbt - what I really like about sbt so far is the interactive console. It allows me to use commands like 'inspect' to get a better idea of what's going on. AFAIK gradle does not provide something like this atm.

回答5:

Sbt and gradle, both are based on statically typed languages....but sbt has few advantages:

• better plugin support, specially autoplugins
• task creation and dependency management between tasks
• sbt specially suits scala projects in the sense that it supports incremental builds and most of the sbt itself is written in scala and sbt build definitions is written in scala
• sbt has interative shell support with many useful built-in tasks
• sbt default lifecycle is pretty useful and can get novice started with pretty less effort