142

Which build tool is the best for Scala? What are the pros and cons of each of them? How to I determine which one of them to use in a project?

Konstantin Solomatov
  • 9,752
  • 6
  • 52
  • 83
  • 5
    I transitioned from Maven to Gradle for Scala projects, due to its superior support for multi-module builds. Twitter [experience](http://www.youtube.com/watch?v=6pfdm-gIZus) with SBT is described by them as "blinding pain" and they are trying to move away from it (with Maven as a stop-gap in that process). – Ben Manes Jul 01 '12 at 05:51
  • 31
    Another cool closed question... – Cedric H. Feb 23 '16 at 20:47
  • 18
    So many good questions I see that are just closed; I don't know who gives the power to these people to arbitrary decide to close a question or not. I don't even pay attention to whether they are close or not any more. – user1888243 Mar 05 '17 at 14:46
  • 2
    Agree. Luckily we have 2 answers before this question is closed. Poor for those who votes to close this question ... – hqt Mar 12 '17 at 13:37

2 Answers2

86

We're using Maven to build Scala projects at work because it integrates well with our CI server. We could just run a shell script to kick off a build, of course, but we've got a bunch of other information coming out of Maven that we want to go into CI. That's about the only reason I can think of to use Maven for a Scala project.

Otherwise, just use SBT. You get access to the same dependencies (really the best part about maven, IMHO). You also get the incremental compilation, which is huge. The ability to start up a shell inside of your project, which is also great.

ScalaMock only works with SBT, and you're probably going to want to use that rather than a Java mocking library. On top of that, it's much easier to extend SBT since you can write full scala code in the build file, so you don't have to go through all the rigamarole of writing a Mojo.

In short, just use SBT unless you really need tight integration into your CI server.

J.Olufsen
  • 12,049
  • 39
  • 108
  • 171
mblinn
  • 3,074
  • 15
  • 15
  • 21
    I don't disagree with any of the above, but just wanted to point out that I'm in the process of writing [ScalaMock 3](http://www.paulbutcher.com/2012/06/scalamock-3-0-preview-release/), one of the primary goals of which is to make supporting other build systems easier. – Paul Butcher Jul 01 '12 at 09:41
  • Wow great, because I'm not sure I'm going to be able to use SBT at work anytime soon. Looking forward to it! – mblinn Jul 01 '12 at 13:51
  • 1
    Just for completeness, it's worth mentioning that ScalaMock 2 works just fine with *any* build system (it's just a jar) as long as you don't need to make use of generated mocks (i.e. as long as you only need to mock traits/interfaces). – Paul Butcher Jul 01 '12 at 13:59
  • Fair point, unfortunately that's about the only reason we're using a mocking framework in the first place :-) – mblinn Jul 01 '12 at 14:59
  • 6
    [scala-maven-plugin provides the save incremental compilation as SBT](http://davidb.github.com/scala-maven-plugin/example_incremental.html) – Nikita Volkov Nov 13 '12 at 14:52
  • 3
    why didn't they just write an incremental compilation for maven? IMHO, sbt is an archexample of an untreated NIH syndrome... – Cpt. Senkfuss Feb 19 '14 at 14:25
  • 1
    Why problems with CI due to SBT? – Daniel Aug 19 '15 at 19:32
20

The question is in danger of just generating lots of opinions; it would be better to have a clear list of requirements or a description of your environment, previous knowledge, etc.

FWIW, there are more opinions in this scala mailing list thread.

My 2c are: Go with sbt if you don't have specific requirements

  • for simple projects, it's totally effortless (you don't even need a build file until you have dependencies)
  • it is commonly used across Scala open source projects. You can easily learn about configuration by peeking into other people's projects. Plus many projects assume you use sbt and provide you with ready-made copy+paste instruction for adding them as a dependency to your project.
  • if you use IntelliJ IDEA, it can be totally integrated. You can have IDEA use sbt to continuously compile your project, and vice versa you can use sbt to quickly generate IDEA projects. The last is extremely useful if you are in a 'snapshot' cycle with depending on other of your own libraries which are bumped from minor version to minor version -- just close the project, update the version in the build file, re-run the gen-idea task, and re-open the project: updates done.
  • comes ready with most tasks you will need (compile, test, run, doc, publish-local, console) -- the console is one of the best features.
  • some people highlight the feature that dependencies can be source repositories directly grabbed from GitHub. I haven't used this so can't comment here.

Some people hate sbt because it uses Ivy for dependency management (I can't comment on its pros and cons, but most of the time it is a non-issue), some people hate sbt because you specify the build file in terms of a Scala DSL instead of XML. Some people were disappointed that sbt's format changed from v0.7 to v0.10, but obviously, migration won't affect you if you start from scratch.

J.Olufsen
  • 12,049
  • 39
  • 108
  • 171
0__
  • 64,257
  • 16
  • 158
  • 253
  • 28
    I hate sbt because its abuse of symbolic operators and some stupid decisions, such as both support .sbt and .scala definition formats but put them in different locations, and statements in .sbt must be separated by at least empty line, etc. The documents of sbt are improving but not good enough at this moment. What I miss most is some complete(minimal to real-world complex) .sbt/.scala sample files explained line by line, covering all sbt features. That said, I use sbt daily because Maven sucks much more. – xiefei Jul 01 '12 at 14:21
  • 6
    Too bad that this question was closed, I am sure there are factual differences as well: for example this excerpt from the Manning book about SBT: "If there are dependencies between Maven goals (say one goal produces a file which is consumed by another) then you can’t parallelize your build with Maven. With sbt, you have to specify an explicit dependency between tasks. This enables sbt to run tasks in parallel BY DEFAULT. If task A depends on B, and C also depends on B, then sbt run task B and then runs A and C in parallel." Hope this comment helps some readers. – jhegedus Feb 02 '14 at 12:53
  • 24
    I found this thread very useful. I very often think that Stackoverflow moderators close threads too eagerly. Who cares if they're "off topic" when they're very often exactly what the users are looking for (and find through web searches). It's as if Stackoverflow mods are trying to intentionally recreate [xkcd 979](https://xkcd.com/979/). – Ville Apr 10 '15 at 22:25
  • 3
    @Ville My thoughts, too. Downvoting, editing and closing has become too aggressive. – ankush981 Nov 25 '16 at 07:49
  • 3
    For anyone looking at this now, @xiefei's complaints have been addressed. SBT has dropped a lot of the more custom operators/syntax, and statements in /sbt files no longer need whitespace separations. – Grogs Mar 28 '17 at 16:56