What's That Noise?! [Ian Kallen's Weblog]

« Programmatic Elastic... | Main | Scala Regular Expres... »

20100724 Saturday July 24, 2010

Getting Started with a Scala 2.8 Toolchain

With the release of version 2.8 and enthusiasm amongst my current project's collaborators, I've fired up my latent interest in scala. There's a lot to like about scala: function and object orientation, message based concurrency and JVM garbage collection, JITing, etc; it's a really interesting language. The initial creature comforts I've been looking for are a development, build and test environment I can be productive in. At present, it looks like the best tools for me to get rolling are IntelliJ, sbt and ScalaTest. In this post, I'll recount the setup I've arrived at on a MacBook Pro (Snow Leopard), so far so good.


I've used Eclipse for years and there's a lot I like about it but I've also had stability problems, particularly as plugins are added/removed from the installation (stay away from the Aptana ruby plugin, every attempt to use it results in an unstable Eclipse for me). So I got a new version of IntelliJ ("Community Edition"); the Scala plugin for v2.8 doesn't work with the IntelliJ v9.0.2 release so the next task was to grab and install a pre-release of v9.0.3 (see ideaIC-95.413.dmg). I downloaded recent build of the scala plugin (see scala-intellij-bin-0.3.1866.zip) and unzipped it in IntelliJ's plugins directory (in my case, "/Applications/IntelliJ IDEA 9.0.3 CE.app/plugins/"). I launched IntelliJ, Scala v2.8 support was enabled.


I've had love/hate relationships in the past with ant and maven; there's a lot to love for flexibility with the former and consistency with the latter (hat tip at "convention over configuration"). There's a lot to hate with the tedious XML maintenance that comes with both. So this go around, I'm kicking the tires on simple build tool. One of the really nice bits about sbt is that it has a shell you can run build commands in; instead of waiting for the (slow) JVM launch time everytime you build/test you can incur the launch penalty once to launch the shell and re-run those tasks from within the sbt shell. Once sbt is setup, a project can be started from the console like this: $ sbt update
You'll go into a dialog like this:

Project does not exist, create new project? (y/N/s) y
Name: scratch
Organization: ohai
Version [1.0]: 0.1
Scala version [2.7.7]: 2.8.0
sbt version [0.7.4]:
Now I want sbt to not only bootstrap the build system but also bootstrap the IntelliJ project. There's an sbt plugin for that. Ironically, bringing up the develop project requires creating folder structures and code artifacts... which is what your development environment should be helping you with. While we're in there, we'll declare our dependency on the test framework we want (why ScalaTest isn't in the scala stdlib is mysterious to me; c'mon scala, it's 2010, python and ruby have both shipped with test support for years). So, fallback to console commands and vi (I don't do emacs) or lean on Textmate.
$ mkdir project/build
$ vi project/build/Project.scala
import sbt._
class Project(info: ProjectInfo) extends DefaultProject(info) with IdeaProject { 
    // v1.2 is the current version compatible with scala 2.8 
    // see http://www.scalatest.org/download
    val scalatest = "org.scalatest" % "scalatest" % "1.2" % "test->default"
$ mkdir -p project/plugins/src
$ vi project/plugins/src/Plugins.scala
import sbt._
class Plugins(info: ProjectInfo) extends PluginDefinition(info) {
  val repo = "GH-pages repo" at "http://mpeltonen.github.com/maven/"
  val idea = "com.github.mpeltonen" % "sbt-idea-plugin" % "0.1-SNAPSHOT"
$ sbt update
$ sbt idea
Back in IntelliJ, do "File" > "New Module" > select "Import existing module" and specify the path to the "scratch.iml" file that that last console command produced.

Note how we declared our dependency on the test library and the repository to get it from with two lines of code, not the several lines of XML that would be used for each in maven.


Back in IntelliJ, right click on src/main/scala and select "New" > "Package" and specify "ohai.scratch". Right click on that package and select "New" > "Scala Class", we'll create a class ohai.scratch.Bicycle - in the editor put something like

package ohai.scratch
class Bicycle {
  var turns = 0
  def pedal { turns +=1 }
Now to test our bicycle, do similar package and class creation steps in the src/test/scala folder to create ohai.scratch.test.BicycleTest:
package ohai.scratch.test
import org.scalatest.Spec
import ohai.scratch.Bicycle
class BicycleSpec extends Spec {
  describe("A bicycle, prior to any pedaling -") {
    val bike = new Bicycle()

    it("pedal should not have turned") {
      expect(0) { bike.turns }

  describe("A bicycle") {
    val bike = new Bicycle()

    it("after pedaling once, it should have one turn") {
      expect(1) { bike.turns }
Back at your console, go into the sbt shell by typing "sbt" again. In the sbt shell, type "test". In the editor, make your bicycle do more things, write tests for those things (or reverse the order, TDD style) and type "test" again in the sbt shell. Lather, rinse, repeat, have fun.

( Jul 24 2010, 11:51:30 AM PDT ) Permalink
Comments [4]


Nice post, Ian. Fyi, Netbeans has worked pretty well for me for serious development (I haven't tried Eclipse in a while). Also, a shameless plug: consider giving Kojo (http://www.kogics.net/sf:kojo) a shot for your Scala REPL needs. Feedback welcome.

Posted by Lalit Pant on July 25, 2010 at 04:53 AM PDT #

Great, this describes exactly what I've been doing. For added fun: just type "sbt", type "~test" and from then on, the tests will run whenever either the main source or the tests have changed. Two small errors in your instructions: 1) the Project needs "with IdeaPlugin" instead of IdeaProject. 2) the package and class name for your test class and the source you present are not in sync. Anyway, it's good to see this written down.

Posted by Bart Schuller on July 25, 2010 at 04:53 AM PDT #

You can make sbt perform a cheap form of CI by using ~test, rather than test. That will monitor your working tree, and if any file is modified (ie. anything is saved), sbt will re-run all your tests automatically :). Also, I'd personally recommend ScalaSpecs over ScalaTest for writing Specs; the syntax is a little cleaner.

Posted by Simon on July 25, 2010 at 04:53 AM PDT #

Wow, great feedback! The "cheap CI" in sbt seems like it could be "the killer app" for sbt over ant and maven. I'll check out kojo too, I tried getting my son hacking on python and pygame; I might try again with kojo :)

Posted by Ian Kallen on July 25, 2010 at 05:08 AM PDT #

Post a Comment:

Comments are closed for this entry.