It is extremely inconsistent. The config file is a list of Scala expressions, however it is not a valid Scala code as a whole. And when you want subprojects, then suddenly the config file is not able to do that, you need to setup another directory with a totally different style of config to do that. On the other hand the interactive console is a killer feature, agreed.

I don't really think it is inconsistent. Sbt has two methods for configuring your projects. You can use a limited configuration file that has less boiler plate but also doesn't allow you to configure as much. The alternative is that you can use the full configuration that has more boilerplate but lets you configure everything. The reason I don't think this is inconsistent because the full configuration is a strict superset of of the limited configuration, both syntactically and semantically (with the exception that expressions need to be added to sequences instead of separated by blank lines).

Question, doesn't the full configuration require you to put your config stuff in multiple files? A lot of files?

The sbt 'directory of configuration' was always a bummer for me. The single pom.xml is a nice mechanism. Also maven has good CI compatibility.

The way I think of it is that maven has a good way of specifying a build. The mvn command is the slow, but complete, way of building. The normal development lifecycle is to load your maven model into an IDE then go from there, using IntelliJ's incremental build support, etc.

SBT in other words, solves a problem I don't have.

The other major problem is last year, SBT was a fucking train wreck between 0.7, 0.8, 0.9 and 0.10. Now that we are a YEAR out from that yeah sure maybe it's a lot better. I'd give it another year before I'd seriously try it again.

In the mean time, I am more interested in kotlin for sane static typed JVM languages, and clojure for real functional sauce. Scala is too slow for me :-/

SBT actually only requires 2 configuration files (even for multi-project builds). One for SBT plugins and one for everything else. You can use more files for organizational purposes but they are not necessary.

I actually like 'directory of configuration'. The SBT build configuration is actually an SBT project itself. So you can use a lot of the same tools to trouble shoot the build configuration that you would use to troubleshoot the build itself. Also, this means that in some cases (such as multi-project builds) you can use much fewer files.

I'm not sure about CI compatibility. I know that Jenkins/Hudson have SBT support but I have never tried to use it.

I actually think that way that most IDEs interact with maven builds is less complete than what you have with SBT. For example, frequently you need specify your build configuration again if you want your IDE to do incremental compilation or to run individual tests. This can be very painful if your build contains anything out of the ordinary. With SBT you just attach a remote debugger to a long running SBT process and then let SBT due all of the building and running. It takes care of the automatic incremental compilation and lets you run individual tests (which, unlike most IDEs, it can be configured to run tests automatically and it can probably run them much faster).

I can certainly understand if the previous 0.7 to 0.10 jump made you nervous about SBT. However, I think that SBT has matured a lot in the year and a half since then. I think it has finally reached a stability point where it is ready for general use. In particular I think the 0.12.x series is where this finally occurred. It has now has a steady release process and has fixed issues that SBT (along with Scala the language) had, in the past, with binary compatibility.

EDIT: lost a bunch of text in the submit, had to retype

A bit late to this discussion, but just want to add a simple clarification that really helped me grok sbt, for posterity:

There are three types of sbt config files: .properties, .sbt, .scala.

* .properties: pure key-value text file

* .sbt: SBT DSL

* .scala: full valid Scala code

I found this little nugget buried deep in the old SBt Github wiki. Now that SBT has its own website, its partially explained in the first few lines:

http://www.scala-sbt.org/

...

* .sbt build definition uses a Scala-based "domain-specific language" (DSL)

* More advanced .scala build definitions and extensions use the full flexibility of unrestricted Scala code

...

I prefer Gradle for all polyglot programming, and their recent release upped the Scala support in it