Not directly related, but: do the world a favor and build a new SBT! This <<= one += is a bit -> """strange""" .
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)
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
<groupId>com.foocorp</groupId>
<artifactId>foo</artifactId>
<version>1.2</version>
"com.foocorp" % "foo" % "1.2"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.
libraryDependencies += "com.lihaoyi" %% "scalatags" % "0.4.3"
libraryDependencies += "com.lihaoyi" %%% "scalatags" % "0.4.3"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...
ModuleID(organization = "com.foocorp", name = "foo", revision = "1.2")I won't go back.
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.
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.
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.
I'd rather just change a single file instead.
It's a good way to differentiate football-team partisanship from actual principles (not that any principle applies 100% of the time).
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.