Month: June 2014

I’ve been slowly starting to explore web development with Scala via the Play Framework.

Coming from a PHP background, it has been useful for me to make connections between the two development worlds. For instance, how do you manage dependencies in your Scala project? How is it similar to using Composer to manage PHP dependencies? How are they different?

Scala has a very powerful tool called sbt , which is an acronym for Scala Build Tool. Part of its functionality offers a way to manage your application’s dependencies.

When you create a new Play application via the command line, there exists a build.sbt file in the root directory of the application. If you open that file, you’ll see the following code :

libraryDependencies ++= Seq(
jdbc,
anorm,
cache,
ws
)

** Note: the sbt allows two conventions for managing builds, including the build.sbt approach which is the simpler and more concise approach. If you need the full expressive power of Scala to manage more complicated builds, you can use .scala files.

It’s important to note here that this is actual Scala code. Unlike Composer, which uses a JSON structure to manage dependencies, the code above is using Scala’s Seq object to define multiple dependencies at once. The ++= operate is simply a shorthand for:

libraryDependencies = libraryDependencies ++ Seq(//dependencies)

The ++ operator “returns a new sequence containing the elements from the left hand operand followed by the elements from the right hand operand.”

When you need to include more libraries for your dependencies, you can simply edit this list to include additional libraries. For instance, with the application I am building, I wanted to use an ORM like library to manage my data model. After doing some research, I found slick, which is an FPM that allows access to the data model using similar functional techniques that Scala provides for its core collection objects.

In slick’s README documentation, it states the following must be added to the application’s dependencies:

The syntax here was a bit confusing at first look, but it is follows a standard notation:

groupID%artifactID%revision

groupID is a token that allows artifacts to grouped together, artifactID is the token that refers to the actual dependency within the Group, and revision is the version number you require. This meta data will be transferred to Apache Ivy, which is the dependency manager that sbt delegates to when resolving your application’s dependencies.

You may have noticed the double percentage (%%) in:

“com.typesafe.slick” %% “slick” % “2.0.2”

and

“com.typesafe.play” %% “play-slick” % “0.6.0.1”

The %% is a shorthand that includes your application’s version of Scala to properly resolve your dependency. This small detail was actually very important when I attempted to include slick as a dependency within my application. Every time I tried to update my application via sbt’s update command, I kept getting errors stating that the slick dependencies could not be resolved. Ultimately, the reason for this was because Typesafe Activator includes Scala 2.11 within its standard download, which Slick currently does not support. In order to bypass this and continue with development, I just altered the build.sbt ‘s scalaVersion to:

scalaVersion := "2.10.4"

and then re-compiled and re-ran the eclipse command (which is the IDE I’ve chosen to use, but Play has support for others)

Once you add a new dependency to the build.sbt file, you need to run update within the console or simply compile (which normally runs the update command) to download the actual libraries from their repositories into your application.

It’s also important to note that when resolving dependencies, sbt will only look in the standard Maven repositories. If the library you application is dependent on does not exist in the standard location, you’ll have to add a custom resolver to map the dependency to the proper location. I haven’t had the opportunity to deal with this yet.