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.