After learning sbt I've found it to be one of my favorite build tools out there. The fact that the build.sbt file is basically just a dialect of Scala allows for some very complex build jobs to be done easily.

Also the simplifications coming with sbt 1.0 like removing the Build.scala and dropping support for multiple build.sbt files makes it a bit cleaner in my mind at least. Before everything was spread around in multiple files (and possible 2 different build definition styles with the .sbt and .scala files) instead now everything is in pretty much one single file with a clean enough syntax for anyone to learn. (as someone said you only really need to know :=, += and +== of which the latter 2 function the same as they do in the standard lib for collections)

edit: Sorry was wrong about the multiple build.sbt support. Its still in but working with a single build.sbt has been made easier over the 0.13.x versions and we reverted all of our multi project builds into that and I just assumed it was being dropped (We also had a lot of Build.scala stuff so I guess i got mixed)

Do you have a link for dropping support for multiple build.sbt files? I can find a reference to it and I'll have to adjust my project if that is the case

Strongly agree. SBT really is puzzling and (IMO) overcomplicated. Someone is working on an experimental alternative called CBT which is pure Scala (as in: less DSL like syntax)

I'm bummed that CBT doesn't stand for "Complex Build Tool"

I'm not even sure why the acronym stands for simple build tool.

I think they refitted the acronym into "Scala Build Tool" a few years ago

What was the original meaning then ? sluggish bloat transducer ?

Sucks big time

indeed, they did!

Hi there. I am that "someone". CBT is coming along very nicely. It is growing into a nice little community. We are working on getting the last bugs out and establishing the basic range of important plugins right now https://github.com/cvogt/cbt/

CBT is very developer friendly, fast, simple, easy to use. Join us on gitter https://gitter.im/cvogt/cbt or check out my Scala Days talk about it :) https://www.youtube.com/watch?v=5COKEp7ItZk

I recently wrote an sbt plugin. And I found that sbt became much easier after learning the core concepts. The book 'Sbt in Action' explains it very well and also contains a great comparison of build tools; what they historically brought to the table.

I shouldn't have to read a book in order to understand a "simple" build tool. And I'm for damn sure not paying for it. Make something overly complex and sells a book for it. Great business model!!!

Like many things, there's a trade-off between up-front learning cost to gain expressiveness and usefulness later, and lower up-front cost at the expense of explicit verbosity later.

These days, you only need to use 3 of those operators: := for assignment, += for adding one item, and ++= for adding multiple. := is a bit weird since you can't override `=`, but the other two are exactly the same as you'd use with the standard collections library.

It's not only about the operators. The whole tools is not really straightforward. A great part of the time I just copy some magical strings into the build.sbt and sometimes it actually works. I tried learning it with understanding, believe me.

Just use Maven. It will be the lowest maintenance cost over time for your project. Nothing else matters, it's a frickin build system -- get it working and move on.

I disagree. I migrated a multi-project build from Maven to SBT. From thousands of lines of XML to 50 or less in SBT. So much redundancy was removed, and the project is much easier to maintain now because of it. SBT has a learning curve, yes, but once you get there I believe the maintenance cost is actually lower than with Maven, at least for more complicated projects.

I completely disagree that SBT or any non declarative build system is that much superior long term over Maven.

Maven is not a really like any of the other build systems. I would say most build systems are glorified Make. Maven is not.

SBT, Gradle, and even old school Ant seem far less verbose than Maven but Maven really shines when you have hundreds of projects in an organization. You can get extreme consistency.

You don't have to have everything checked in one gigantic source tree which makes open sourcing projects subsets of your code base easier. Yeah Gradle and SBT can sort of do this but not nearly as decoupled as Maven does it (generally with Gradle and SBT you have to do some path magic).

Just about every PL and editor can readily edit Maven pom files. That means with out loosing comments or spaces you can have scripts go and rewrite hundreds of pom files or even just do a sanity check to make sure that they are consistent.

This is the complete opposite with build systems where basically the build system is turing complete scripting language. Projects have major drift and you loose lots of consistency.

> That means with out loosing comments or spaces you can have scripts go and rewrite hundreds of pom files or even just do a sanity check to make sure that they are consistent.

I'd rather just change a single file instead.

> build systems where basically the build system is turing complete scripting language

Not only that, but virtually no-one uses this Turing-Complete facility. In Gradle at least, I never see if- and for-statements. By using dynamically-typed Groovy in Gradle, you not only lose the ability for massive rewrites, but often also don't get any of the TC benefits. Perhaps it's different using statically-typed Scala in SBT, or Kotlin in Gradle 3.

Yeah, the hilarious part of scala hyperpartisans (and i like scala) insisting that SBT is great is when you point out that Maven is declarative and SBT is imperative.. in other words the exact opposite of scala dogma.

It's a good way to differentiate football-team partisanship from actual principles (not that any principle applies 100% of the time).

Any rewrite simplifies things. What redundancy did you have in Maven that you couldn't remove? You know about parent poms and profiles, right?

Maven is an archaic, verbose nightmare compared to SBT. SBT can be annoyingly esoteric at times, but even for the simplest thing like "add these JARs and compile," SBT wins over Maven, no question.

Not true. Maven may be verbose, but

    <groupId>com.foocorp</groupId>
    <artifactId>foo</artifactId>
    <version>1.2</version>

is far less archaic and more understandable than

    "com.foocorp" % "foo" % "1.2"

actually, the latter is far more readable without markup making my eyes bleed.

I generally prefer gradle's method of 'com.foocorp:foo:1.2' but that isn't acceptable statically. scala string interpolators could make it a thing, though.

Unfortunately, we have things like this in the mix...

  libraryDependencies += "com.lihaoyi" %% "scalatags" % "0.4.3"

  libraryDependencies += "com.lihaoyi" %%% "scalatags" % "0.4.3"

To be fair you'd only be using one or the other, `%%` for jvm-only, and `%%%` for cross platform jvm/js builds.

Far and away the biggest blocker to learning sbt is the shaky IDE support for the build project. Apparently that's coming up next in 1.0; will be nice to click through to source from sbt build files and instantly grok what X symbol means. Have wasted a lot of time over the years slogging through documentation...

A build definition format that allows arbitrary code anywhere is always going to have less-good IDE support than one based on declarative documents.

I don't see why, as long as the IDE sees the build file as a genuine source file for the language it's written in.

The IDE would need to run it to understand the build definition, which then gets into halting-problem issues.

I'd just use

  ModuleID(organization = "com.foocorp", name = "foo", revision = "1.2")

I replaced a 500 line buggy maven nightmare with a 50 line SBT file that caches build targets.

I won't go back.

What was the functionality?

If you stick to defining dependencies maven works perfectly. If you encapsulate whatever other crap you want to do as proper maven plugins maven works perfectly. It's the people who decide they absolutely need to output to a different folder on Tuesdays but can't be bothered to write a proper tested plugin for doing that who get themselves in trouble.

It was an Atlassian plugin, written in Scala. I also wanted to download the JS Closure Library and minify JS with the Closure Compiler.

Your comment is accurate. If you want to do a very specific set of things, Maven works fine. If you want anything outside that, it gets much harder.

Can second this. SBT is terrible. It gets even worse in combination with IntelliJ and complex project setups.

If this is ever going to happen I feel like some level of SBT plugin compatibility may be a good call. I really dislike SBT, but a lot of the plugins are top-notch (sbt-android and sbt-android-protify are two great examples).

I agree. As a casual Scala developer I feel like SBT has always been a disaster. Does anyone know why Gradle isn't more popular for Scala development? I've had generally very positive experiences using it with Java.

because gradle is slow, and the dsl is a disaster compared to sbt

SBT's IDE support isn't great by any means, but it's way ahead of what I've ever seen with Gradle.

IIRC you can replace SBT with more Java-like tools like Maven (if you prefer xml) or Gradle (if you prefer... Actually iirc gradle is ambiguous about language these days).

In my experience, to some degree. If you are using Play, for example, the Gradle plugin is currently held on Play 2.3. Play 2.4 is experimental, 2.5 is nowhere to be seen.