comparing sbt and Gradle

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.

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.

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.

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)