We've recently had some questions about Typesafe Activator and how it relates to other projects on the Typesafe Platform, such as Scala, Akka, Play Framework, and sbt. The tool has evolved a lot since we launched it over a year ago, both in use cases and features, and we're continually working on improvements to make it the best way to get started with our technology.
We want to give you a straightforward technical breakdown on what we’re currently working on and why.
Let’s go through some specific problems we’re trying to solve.
At Typesafe we work on several projects, including Scala, Akka, Play, and sbt.
Newcomers to the platform might see any number of suggested things to install:
Advanced users know that most of these “distributions” (.tar.gz and zips) are not needed; by grabbing the sbt launcher jar, you can get everything else as a dependency.This may explain why the distributions tend to contain outdated odds and ends, because advanced users often don’t use or test these distributions.
Meanwhile, newcomers might download several different things and then not know where to start or which odds and ends are outdated. We want to fix that.
Our solution is to factor out the best parts from all the different downloads and put them in a single download, which we are calling the Typesafe Reactive Platform. The platform download includes a script “activator” which is equivalent to the former “play” script, but it’s no longer specific to Play. It also adds a new, optional UI mode.
activator enters an sbt console.activator new command works like play new but uses a fully general template system rather than a couple of hardcoded choices.activator ui command opens up the optional UI mode.sbt or play to activator, you shouldn’t notice much difference because all of these commands are wrapper scripts around sbt launchers.We offer two flavors of the Typesafe Reactive Platform download. The “full” flavor is like the former Play distribution, with all dependencies bundled for offline use. The “mini” flavor is like downloading the sbt launch jar, so it’s a tiny download that fetches dependencies later on demand.
Formerly, we referred to the unified download by saying “download Activator”; this was confusing, because people thought the point of the download was to get the optional UI mode.
From now on we plan to say “download Play, Akka, and Scala” or “download the Typesafe Reactive Platform” to reflect that the download gets you everything -- either literally everything in one big zip (the “full” version), or a bootstrap tool that can fetch everything on demand (the “mini” version).
We wanted to smooth the first few minutes after a newcomer downloads the platform. Presumably they want to try out one of the technologies -- be it Scala, Akka, Play, or Slick.
To smooth this out we don’t want to have steps like “go install and configure an IDE” or “install these 5 things” or “learn to use a build tool” -- we want it to just work, quickly. So that’s the idea of tutorials inside Activator, along with a very basic code editor. Someone can walk through “Hello, World” for Akka or Play without doing a bunch of setup.
Of course they’ll want to set up a full editor or IDE later on. Activator’s UI isn’t intended to replace a full editor.
To cover these first 15 minutes, we created a template system which has some pretty neat features. Templates are simply prebuilt sample projects which can contain a tutorial. Templates can be browsed online, browsed in the Activator UI, or tab-completed with activator new. Anyone can create a template and publish it to the catalog.
We see two broad categories of template:
To mark a template as a seed template, just add the seed tag when you create the template. Then people will know to use it when they’re starting a new project. Without that tag, templates are assumed to be tutorials.
Seed templates are intended to replace the “play new” feature of the old play script. Previously Play would offer two options (create a Scala or Java project). We’ll still highlight a short list of options in Activator for Play 2.3. But you can browse the full list of seed templates for one that best suits the project you’re starting.
A design goal of Activator’s template system is that templates are just regular projects. You can go to any of the templates on GitHub -- in fact, on each template’s catalog page, we link to GitHub -- and if you clone the repository you should be able to build and run it with command line sbt (or command line Activator).
For convenience we also generate a “template bundle” for each template. A template bundle is simply the project, zipped up, with the Activator mini distribution stuck into the same zip. This means you can download the bundle, unpack, and run “./activator” to build it. No need to download Scala or sbt or anything else -- just the bundle itself.
Template bundles are great if you just want the code for a template without any extra stuff, or if you’re writing a blog post around a template and want an easy download for readers to try it out.
There are at least five ways to use a template (we want these as accessible as possible):
activator new”Check out, for example, the hello-scala template.
We’ve also worked hard to make it easy to create templates. This starts with the fact that they’re just projects. Here’s how you publish a template:
tutorial/index.html”That’s it!
There are a few more details explained at http://typesafe.com/activator/template/contribute, but nothing like rocket science.
Right now, the optional Activator UI is intended to be a platform for tutorials and templates. It is not intended to be more than that, yet.
However, we want it to be more useful. Right now, many developers run the sbt command line alongside their editor or IDE. That will continue to be an option, but we’d like the UI to be a viable alternative -- a full-power frontend to sbt.
To get there, we’ve been doing a lot of work on sbt itself to make it work robustly as a UI backend. We hope this work will benefit not only Activator, but also any other tool which interacts with sbt -- perhaps Eclipse, IntelliJ, other editors, and even Play’s in-browser UI.
You can check out the “sbt client” API we’re building over in the sbt-remote-control project. To explore that codebase, a good starting point might be SbtClient. In addition to a client-server split, we implemented AutoPlugin, and plan to improve support for forking and manipulating processes. All of these enhancements help sbt work better as a UI backend.
In the current Activator codebase, the UI is retrofitted onto sbt and it’s only able to run a few hardcoded sbt tasks. It also has some major limitations on real-world projects (no support for multiple projects in one build, for example).
When we switch over to the new sbt, the UI will be able to do anything the sbt command line can do -- and hopefully more, as we take advantage of pixels to display information.
We hope to make Activator’s UI mode a useful companion to your editor or IDE, just as the sbt command line mode is today. Developers will be able to choose command line or UI, according to their preferences or depending on the task at hand. In the UI we hope to make many everyday tasks easier. And we hope to enable improvements in other tools such as IDEs, as they take advantage of the sbt changes we’re making.
In short, our three directions with Activator right now:
All three of these will be evolving and improving; the third in particular does not exist yet. We’ll be developing it over here in the Activator GitHub repository if you are interested in checking it out.
By the way... we’re running an Activator template contest leading up to ScalaDays 2014. First prize is a helicopter drone so if you’ve been thinking of creating a template, this might be the time to do it. It’s a great way to increase visibility for your favorite technology.
