Pros and cons of using sbt vs maven in Scala project

Question

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?

Solution 1

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.

Solution 2

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.

Comments

[Ben Manes]

I transitioned from Maven to Gradle for Scala projects, due to its superior support for multi-module builds. Twitter experience 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).

[Cedric H.]

Another cool closed question...

[user1888243]

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.

[hqt]

Agree. Luckily we have 2 answers before this question is closed. Poor for those who votes to close this question ...

[Paul Butcher]

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, one of the primary goals of which is to make supporting other build systems easier.

[mblinn]

Wow great, because I'm not sure I'm going to be able to use SBT at work anytime soon. Looking forward to it!

[Paul Butcher]

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).

[xiefei]

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.

[mblinn]

Fair point, unfortunately that's about the only reason we're using a mocking framework in the first place :-)

[Nikita Volkov]

scala-maven-plugin provides the save incremental compilation as SBT

[jhegedus]

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.

[Cpt. Senkfuss]

why didn't they just write an incremental compilation for maven? IMHO, sbt is an archexample of an untreated NIH syndrome...

[Ville]

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.

[Daniel]

Why problems with CI due to SBT?

[ankush981]

@Ville My thoughts, too. Downvoting, editing and closing has become too aggressive.

[cocoder]

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.