Why do you feel that sbt isn't simple/a disaster? I actually think it is the nicest of the build tools on JVM. I can set up basic projects with no configuration. Also, its triggered build feature[1] combined with its interactive console is a killer feature set that I think all build tools should have.
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
As an former Eclipse user I had to switch to IntelliJ for the last 4 months and use it on a daily basis. I was very surprised how well the Scala plugin works. Excellent code completion, code search and refactoring options. I tried also Scala IDE in the Coursera Course and think the overall development experience of IntelliJ (with Java and Scala) is much better.
you can edit the pom.xml file, and have your project adjusted immediately. intellij will download and add the new jar to the classpath... BAM
intellij is really a much better experience in developing than eclipse. Lots of fit and finish things, also intellij is very keyboard-centric, so whereas eclipse had lots of graphical widgety things, intellij has all your normal day to day stuff fully keyboard accessible. It's the closest to emacs in an IDE I've ever seen.
I'd recommend using zinc instead if (like me) you aren't too crazy about using sbt. Zinc is basically the incremental compiler part of sbt stripped out, plus nailgun support. Large projects can still take some time to rebuild if critical dependencies were touched by a change.
i really just want intellij compatability. sbt doesnt offer that. it's incremental compiling is not useful because I do my java dev in intellij. So SBT offered me nothing that maven didnt already have, minus a few weirdo things (like putting the scala version in the name/version of a scala library).
To me, I had to give up scala due to lack of tool support. Maybe if you are used to an emacs/gcc paradigm, but I've gotten quite productive in intellij, as much or more than any C++-styled development. Why have another window with compiler output when you could have it inline with the code and using the typographic features?
I could go either way, but with Java, intellij I have 'develop and run anywhere' going on. Sure there are some super edge causes at the highest performance profiles, but that is always hardware specific, and unless you are developing on the same server class boxes you wont find it.
One thing I've found helps a LOT is encapsulation and return type annotation.
If you change a public method, SBT will recompile all users of that class even if they don't use that method. If you change a private method, it's smart enough to recompile only the one file.
Annotating your return types both saves the compiler the effort of figuring out what you meant, and also prevents you from accidentally changing the return type and forcing recompilation of a bunch of client code.
