

Building A Better Build: Our Transition From Ant To SBT - metaprinter
http://codeascraft.com/2014/09/30/building-a-better-build-our-transition-from-ant-to-sbt/

======
ddispaltro
It's taken me a while to understand all the hieroglyphics, but it really is a
solid build system. Take a look at a complex example of cross compiling for
scala.js, a single code base, with shared classes [1], for multiple versions
of Scala.

My biggest complaint early on, was the Ivy resolver. Maven "pom" style
packages didn't work too well. I also know there was talk of using gradle's
resolution system, which was rewrote long ago. Not sure if that went anywhere.

I think the IDE story will simplify, and work better, when sbt supports sbt-
server. The work is being done here [2]. However, it is much better in IDEA 14
and the newest Scala plugin.

[1] [https://github.com/w3c/banana-
rdf/blob/master/project/build....](https://github.com/w3c/banana-
rdf/blob/master/project/build.scala)

[2] [https://github.com/sbt/sbt-remote-control](https://github.com/sbt/sbt-
remote-control)

~~~
saryant
I agree. SBT has a steep learning curve, though fortunately the 0.13.x branch
is much simpler than it was in the past.

Lots of great stuff has been done with SBT plugins as well. I have an SBT
project that will spin up multiple JVMs for distributed integration testing,
build and push Docker images tagged with the current git branch, spin up
external services under test and more. Once you get the hang of it, these
things fall in place easily.

Also, Typesafe has really improved SBT's documentation over the past year.
Plus a lot of the odder syntax choices have been replaced in favor of :=
instead.

~~~
ddispaltro
Totally agree on first point, especially since 0.13.5.

Yeah I think native-packager is great [1].

I wish they didn't bork the template of the docs, it looks terrible. The
content is better though for sure [2].

[1] [https://github.com/sbt/sbt-native-packager](https://github.com/sbt/sbt-
native-packager)

[2] [http://www.scala-sbt.org/0.13/docs/index.html](http://www.scala-
sbt.org/0.13/docs/index.html)

~~~
w4tson
I've just spent the last couple of years investing my time in Gradle.

I'm in a position where I've become productive with the tool. But as is the
way of the freelance software guy (or gal) the decisions that influence the
tech. stack are not in your control.

So I'm being pushed to use the Play! Framework for micro services style arch.
Which I'm happy enough about but afaik that means I'm tied into SBT.

Could you guys give advice for smoothing the learning curve to Sbt? Any
hints/time sucks/resources appreciated

~~~
vorg
In
[http://forums.gradle.org/gradle/topics/revolutionary_new_gra...](http://forums.gradle.org/gradle/topics/revolutionary_new_gradle_features_on_the_2014_roadmap)
, the Gradle founder writes "what is ultimately needed is a fundamental
solution within Gradle that eliminates the overhead in the IDE-to-Gradle
communication". That solution would be to enable any JVM language to be used
with Gradle, not just Groovy. Then you wouldn't be tied to SBT as you then
could use Scala to configure Gradle.

