In the earlier sections, we used the play! console a lot to access the tasks related to our project. Actually, this command-line tool is a customization of Simple Build Tool (SBT).
SBT is a powerful and easily extensible build tool like Maven or Ant. But, where the latter rely exclusively on the external DSLs to manage their configuration, SBT uses an internal Scala DSL for that. Of course, this isn't its only advantage.
What is interesting at this point is that SBT doesn't need any specific integration with IDEs because it's simply Scala code. As one isn't required to know Scala in order to create or update an SBT configuration, let's cover how to deal with its common tasks.
Looking into the project folder, we'll find a Build.scala file, which contains the basic configuration of our build. It briefly defines play.Project: an extension of a regular SBT Project. The following screenshot shows what it contains:
Even if Play! 2 already integrates a lot of libraries that are usually sufficient, it often happens that we need to add new dependencies to our projects to access new features (such as a statistics library) or provided one with a different vision (such as a new logging library).
As an example, we'll add the latest version of Guava (http://code.google.com/p/guava-libraries/) to our project.
As Scala is powerful enough to create DSLs, SBT took the opportunity to provide a DSL to define Ła project. Let's see an example of adding a dependency using this DSL.
For that, the Build.scala file already defines a sequence (appDependencies) that can be seen as an immutable java.util.List in Scala. This sequence is meant to contain all the extra dependencies that we'll need to be added to our project.
As SBT can use the Maven or Ivy repositories, and is configured to check the common public ones, what we'll do is add Guava using its Maven groupId, artifactId, and the required version.
Let's see the syntax:
Later on, this sequence will be used in the play.Project configuration as a parameter.
In the previous section, we saw how to add new dependencies to our projects; but this method will only work for the libraries that have been deployed on public repositories. However, as developers, we'll face two other cases:
Locally built libraries (either open source or owned) that are placed in our local repository
A library that is not available in the common public repositories
The way to go for such cases is to tell the play.Project configuration to look into the other repositories that we have configured, shown as follows:
A DSL is meant to be code-readable by expressing and using business-specific concepts for a specific field. Let's check if it is, by reviewing the repositories' declaration.
A repository is nothing more than a folder that is accessible using a path, and which has a structure that follows some convention. So, a declaration is composed of three things:
For convenience, we store these definitions in val (which are immutable variables) in order to use them in the play.Project declaration. This declaration is done by adding the existing resolvers (or repositories) to our new sequence of repositories (or resolvers) using the ++= operator.