In Part 1 we covered routes, controllers and client side scripting. In the
time since that post, the Play framework released version 2.4 (Damiya) on May
27, 2015. With a major point release there are usually enough changes to warrant
taking some time to rebuild a few things. Since the
is still fairly small, the effort will be minimal. This gives us a good
opportunity to take a look at what is entailed in performing a framework
As before, the source code for this tutorial series is available on github with the code specifically for this post here. Since the code builds on the previous post, you can grab the current state of the project (where part one finished) here.
Updating the reference to Play
project\plugins.sbt change the installed sbt-plugin for Play to reflect
the new version of the framework. As well,
sbt-mocha got a version bump.
In addition, the latest version of play requires sbt version
0.13.8. Open up
project/build.properties and update that reference as well.
Changes in dependencies
When you reload activator, it will download all the new dependencies and then fail in an error.
[info] Done updating. Anorm has been moved to an external module. See https://playframework.com/documentation/2.4.x/Migration24 for details. Project loading failed: (r)etry, (q)uit, (l)ast, or (i)gnore?
Every major release of Play comes with a well documented migration guide. This document outlines how features have changed from the previous version and suggestions on how to bring your code up to speed.
The first change we will need to make is explicitly including the eclipse sbt
plugin. As the migration guide mentions, the eclipse plugin is no longer
included by default. Open up
project/plugins.sbt and add the following line:
Note: at the time of this posting, 4.0.0 was still in Release candidate status, so if this does not work for you, try version “4.0.0-RC2”
Next in the 2.4 migration guide, there is a section explaining how Anorm (the database access library) has been moved from the core framework into a new separate library.
Since we do not currently use Anorm, we can remove that from our
file. The modified
libraryDependencies should now look like this:
In the activator terminal, press
r to retry loading. Activator will
successfully load the application. At this point you will want to regenerate the eclipse settings for the project.
You will notice it download even more dependencies downloaded. At this point
refresh the project in eclipse. You will notice a large number of errors
print out in the IDE. This is because
specs2 which was used for tests in
the initial template has also been pulled out of the core Play distribution.
We can easily add this back by modifying our
libraryDependencies again. We
will also need to add a resolver for the
scalaz-stream dependency as mentioned
in the migration guide.
We need to restart activator and regenerate our eclipse settings again. Once
that is complete, refresh the project in eclipse. Now that it compiles
successfully, the errors disappear, but new warnings about
If you do get errors in eclipse, delete the contents of your
targetfolder, it will be recreated next compile).
We do not have to change this now, but we might as well fix any deprecated
calls when we find them as opposed to getting stuck at a later point. This can
easily be fixed by adding an
import statement and changing one line in the
At this point we can
~ run the application and manually verify it has the
same behavior as before. Looking through the rest of the Migration Guide there
are some interesting things we have not yet had a chance to play with, like the
Dependency Injection changes. (We will get to that eventually, just not
One portion that stands out is the Configuration Changes section. Our
project contains a file named
conf\application.conf that we have not modified
before, but is already out of date!
application.conf and change the following:
Note, your value for application.secret will be different if you created the template on your own. No need to worry about the value yet, just change the configuration parameter name.
Updates to logging
You will also have noticed that while loading the application, there was a
warning about logging features no longer being loaded from the
application.conf. Create a file named
conf/application-logger.xml and add
the following contents.
This gives us application logging at the DEBUG level, but INFO for the rest of play and WARN for everything else. We also get some colors in our logs that are displayed to the activator console.
Remove the old logging parameters from the configuration file as well, since they now serve no purpose.
We now have an up to date version of the application, ready for development with the latest version of the Play framework.
Until next time…
We stepped through the changes required for 2.4 coming from a 2.3 application. Even a tiny application like ours requires some love and attention when a new version of the framework is released. Once you get the hang of it, you can get through the upgrades fairly quickly.
I would strongly recommend reading the Play framework mailing list to get an idea when the milestone and release candidates are available and also to get a handle on how impactful the changes will be to projects you maintain. In addition, the migration guides are helpful to learn about features you may not have even realized existed.
In part 3, we will cover database access, schema creation and migration and build out more of the REST API.