SBT

Everyone likes Scala REPL. REPL is the command line for Scala. It allows you to type Scala expressions that are evaluated immediately and try and explore things. As you saw in the previous chapters, one can simply type scala at the command prompt and start developing complex data pipelines. What is even more convenient is that one can press tab to have auto-completion, a required feature of any fully developed modern IDE (such as Eclipse or IntelliJ, Ctrl +. or Ctrl + Space) by keeping track of the namespace and using reflection mechanisms. Why would we need one extra tool or framework for builds, particularly that other builds management frameworks such as Ant, Maven, and Gradle exist in addition to IDEs? As the SBT authors argue, even though one might compile Scala using the preceding tools, all of them have inefficiencies, as it comes to interactivity and reproducibility of Scala builds (SBT in Action by Joshua Suereth and Matthew Farwell, Nov 2015).

One of the main SBT features for me is interactivity and the ability to seamlessly work with multiple versions of Scala and dependent libraries. In the end, what is critical for software development is the speed with which one can prototype and test new ideas. I used to work on mainframes using punch cards, where the programmers were waiting to execute their programs and ideas, sometimes for hours and days. The efficiency of the computers mattered more, as this was the bottleneck. These days are gone, and a personal laptop is probably having more computing power than rooms full of servers a few decades back. To take advantage of this efficiency, we need to utilize human time more efficiently by speeding up the program development cycle, which also means interactivity and more versions in the repositories.

Apart from the ability to handle multiple versions and REPL, SBT's main features are as follows:

  • Native support for compiling Scala code and integrating with many test frameworks, including JUnit, ScalaTest, and Selenium
  • Build descriptions written in Scala using a DSL
  • Dependency management using Ivy (which also supports Maven-format repositories)
  • Continuous execution, compilation, testing, and deployment
  • Integration with the Scala interpreter for rapid iteration and debugging
  • Support for mixed Java/Scala projects
  • Support for testing and deployment frameworks
  • Ability to complement the tool with custom plugins
  • Parallel execution of tasks

SBT is written in Scala and uses SBT to build itself (bootstrapping or dogfooding). SBT became the de facto build tool for the Scala community, and is used by the Lift and Play frameworks.

While you can download SBT directly from http://www.scala-sbt.org/download, the easiest way to install SBT on Mac is to run MacPorts:

$ port install sbt

You can also run Homebrew:

$ brew install sbt

While other tools exist to create SBT projects, the most straightforward way is to run the bin/create_project.sh script in the GitHub book project repository provided for each chapter:

$ bin/create_project.sh

This will create main and test source subdirectories (but not the code). The project directory contains project-wide settings (refer to project/build.properties). The target will contain compiled classes and build packages (the directory will contain different subdirectories for different versions of Scala, for example, 2.10 and 2.11). Finally, any jars or libraries put into the lib directory will be available across the project (I personally recommend using the libraryDependencies mechanism in the build.sbt file, but not all libraries are available via centralized repositories). This is the minimal setup, and the directory structure may potentially contain multiple subprojects. The Scalastyle plugin will even check the syntax for you (http://www.scalastyle.org/sbt.html). Just add project/plugin.sbt:

$ cat >> project.plugin.sbt << EOF
addSbtPlugin("org.scalastyle" %% "scalastyle-sbt-plugin" % "0.8.0")
EOF

Finally, the SBT creates Scaladoc documentation with the sdbt doc command.

Note

Blank lines and other settings in build.sbt

Probably most of the build.sbt files out there are double spaced: this is a remnant of old versions. You no longer need them. As of version 0.13.7, the definitions do not require extra lines.

There are many other settings that you can use on build.sbt or build.properties, the up-to-date documentation is available at http://www.scala-sbt.org/documentation.html.

When run from the command line, the tool will automatically download and use the dependencies, in this case, graph-{core,constrained,json} and lift-json. In order to run the project, simply type sbt run.

In continuous mode, SBT will automatically detect changes to the source file and rerun the command(s). In order to continuously compile and run the code, type ~~ run after starting REPL with sbt.

To get help on the commands, run the following command:

$ sbt
 [info] Loading global plugins from /Users/akozlov/.sbt/0.13/plugins
[info] Set current project to My Graph Project (in build file:/Users/akozlov/Scala/graph/)
> help

  help                                    Displays this help message or prints detailed help on requested commands (run 'help <command>').
For example, `sbt package` will build a Java jar, as follows:
$  sbt package
[info] Loading global plugins from /Users/akozlov/.sbt/0.13/plugins
[info] Loading project definition from /Users/akozlov/Scala/graph/project
[info] Set current project to My Graph Project (in build file:/Users/akozlov/Scala/graph/)
[info] Updating {file:/Users/akozlov/Scala/graph/}graph...
[info] Resolving jline#jline;2.12.1 ...
[info] Done updating.
$ ls -1 target/scala-2.11/
classes
my-graph-project_2.11-1.0.jar

While SBT will be sufficient for our use even with a simple editor such as vi or Emacs, the sbteclipse project at https://github.com/typesafehub/sbteclipse will create the necessary project files to work with your Eclipse IDE.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset