Building A Better Build: Our Transition From Ant To SBT

Building A Better Build: Our Transition From Ant To SBT(codeascraft.com)

17 points by metaprinter 11 years ago | 7 comments

ddispaltro 11 years ago |

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

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

saryant 11 years ago | |

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 11 years ago | | |

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

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