Ten months ago we posted about architectural changes to Typesafe Activator. After a few a lot of yak shaves, side projects, and detours, we have Activator 1.3.0 based on sbt server, a new setup where multiple clients can share the same instance of sbt. sbt server is also available in ABI-stable protocol-stable form for other clients (IDEs, command line, desktop status icon, whatever you can think of) to try out.
This is a major update for Activator. While we were working on the backend changes, we also overhauled the UI.
Old versions of Activator (in the 1.2.x series) will not auto-update to 1.3.0 for now, because the changes are so large. Instead, you will need to manually opt-in to 1.3.0 by downloading it.
In this blog post, first I’ll tour a few of the new UI features, then I’ll go into some of the technical details for those who follow sbt development or want to know how things work behind the scenes. To try everything for yourself, download 1.3.0 now.
Both the home screen (template selector) and the main application screen have been visually revamped.
Because of the new sbt server backend, the UI can launch and display any sbt task.
The built-in buttons remain for common tasks (compile, run, test), but the search box at the top of Activator’s UI now autocompletes tasks in addition to source files:
We’re now grouping templates based on the Typesafe Reactive Platform in their own category. These templates require a free trial subscription ID, which you can obtain at https://typesafe.com/account/id.
Tutorials can be viewed fullscreen now, and we include prominent placement for tutorial authors - when you create a tutorial, you can provide author information in activator.properties, including a link, logo, and bio, which will be displayed to anyone trying out the tutorial.
Tutorials can also be kept in a pane below or to the side of the application.
The code browser makes it a bit easier to create, rename, and delete files, which people commonly do when following a tutorial:
The Inspect feature allows you to view a list of your actors, information about http requests made to Play, and information about exceptions thrown from actors. Furthermore it is possible to get detailed information about these actors, http requests and exceptions.
Actor list:
For those of you who give presentations using Activator, there’s a new presentation mode which hides the sidebar navigation to create more screen real estate. Turn on presentation mode by clicking the checkbox on the welcome screen (the welcome screen appears when you first open an app, or click the small home icon in the lower left corner next to the Typesafe logo).
While Activator through 1.2.12 wrapped the sbt command line tool (sending it textual commands and parsing its output), Activator 1.3.0 takes advantage of several sbt enhancements to use the sbt engine directly, through a programmatic API. In addition, multiple clients can connect to the same build instance - including Activator to start, but eventually the sbt command line, IDEs, desktop status icons, or whatever else people create.
The enhancements visible to sbt plugin developers are in a plugin called sbt-core-next, and its README goes into a little bit of detail on the new APIs. Plugins can now send structured events to all attached clients, prompt the user without directly requiring a terminal, register serializers for task results, and run jobs in the background (without tying up the main sbt command loop).
Activator is the first client to default to sbt server, but we’d like to move all users of sbt to this model because it allows multiple clients, such as your IDE and the sbt command line, to coexist without stomping on one another. In addition, sbt server can be a significant optimization (sharing the same JVM and compiler instance among various frontends).
When run by Activator 1.3.0, using the new backgroundRun task, the Play Framework’s “dev mode” http server becomes a client of sbt server as well. When you run your web app in dev mode, it connects back to sbt server and asks sbt to rebuild when you reload a page. So the build on reload will be shared between Play and Activator, while in Activator 1.2.12 the two were not coordinated and would break one another.
In Activator 1.3.0 we also fork the dev mode web app into its own JVM, which means it’s easier to debug, instrument, kill, or otherwise manipulate.
If you’re interested, we’ve already seen a good bit of activity in the public sbt-remote-control chatroom, and we’d love to answer questions or talk about possible contributions there.
To extend Activator, it’s now possible to put most of the extension code in an sbt plugin (or use an existing plugin), rather than having to hack on Activator itself. An sbt plugin can communicate with Activator’s JavaScript UI using sbt-core-next APIs, so the only need to modify Activator itself will be the pure UI (JS and HTML). For example, to add Activator support for Play Framework, we modified the Play plugin to send an event containing the application URL when the Play server has started up. We then made the Activator UI display this URL. So there’s no Activator-specific “backend” code, it’s all in the sbt plugin. In the future, we’d like to make Activator’s UI frontend pluggable as well.
It’s a little early to speculate on the roadmap for 2015, but Activator now has a solid foundation with sbt APIs designed to enable multiple clients, both GUI clients and others. Our intent is to focus on refinement and new user-visible features, to help everyone learn more about Scala, Akka, Play, Spark, and other great technologies.
Join us at https://github.com/typesafehub/activator if you’d like to be involved!
