Escalante's Future

Escalante started out as a way to bring in the capabilities and functionality within a managed environment like JBoss Application Server 7 or Wildfly to Scala developers. Among the existing frameworks, Lift has tried to take the most advantage of this combination, so it was an easy place to start at.

Based on our experience of pitching Escalante to Scala developers, it has become clear that managed environments are considered too heavyweight, particularly when it comes to ease of development, and hence most Scala developers building concurrent applications are trying to stay away from them choosing instead to build Akka or Play applications. In other words, Scala developers are focused on building solid, statically typed, applications with the least amount of resistance.

Around the same time as we were working on Escalante 0.3.0 a couple of interesting things happened:

  • First, the Reactive Manifesto came out (July 2013), pretty much laying the foundations for the type of applications that Scala developers have been trying to build.

  • Secondly, Vert.x founder and lead developer, Tim Fox joined Red Hat (January 2013). Vert.x is an polyglot, event-driven application development framework for the Java Virtual Machine which promotes development of reactive applications.

Right until mid-2013, Vert.x's Scala language extension was lagging behind other languages such as Java or Groovy. Tim was very keen to get this effort moving and I started contributing to Vert.x's Scala module, eventually becoming the lead of it.

The amount of feedback received on Vert.x Scala language extension and the community involvement in the project has surpassed anything Escalante had, demonstrating even more where the focus is for Scala developers. They want to easily build multi-node reactive applications that are scalable and fault tolerant. Managed containers, in spite of providing a lot of base middleware and come with good monitoring tools, are rooted in the single node vision and their ease of development is lagging behind.

So, with all this in mind, we have come to the conclusion to not develop Escalante any further. For those Lift users that have tried Escalante, there are other containers out there which should fit your use case.

Thanks to everyone who has been involved in Escalante!

Escalante has a logo!

Yayy!! After months of waiting, Escalante finally has a logo. Many thanks to the JBoss design team, and Cheyenne in particular, for creating such an awesome logo.

The logo represents either a pyramid or mountain, depending on which side you look at. It's a very nice visual trick. On the left, the pyramid with the stairs and on the right, the mountain, both of which we encourage you to climb :). This is precisely what the name 'Escalante' means, something that's climbing or ascending.

In the next few weeks the website's design will change to adopt the logo and style.

Escalante 0.3.0 out now with Play Framework 2.1 support!

We're pleased to announce the next official release of Escalante - version 0.3.0. We consider this release to be beta quality, and lacks some of the features and API stability that will end up in the 1.0.0 release.

What is Escalante?

If this is the first time you've ever heard of Escalante, check out our FAQ section to find out more about Escalante.

What's in this release?

The main focus of this release has been adding support for Play Framework 2.1 scala web applications to Escalante. This means that Play 2.1 applications can be built, deployed and run on top of Escalante just like a normal Play application but with some limitations. To help Play users deploy applications on top of Escalante, quickstart applications have been developed and these are the best starting point.

Here's a summary of other highlights of this release:

  • Lift integration has been enhanced in order to support Lift 2.5 applications. The "Hello World" Lift quickstart has been upgraded to use Lift 2.5, but the other Lift quickstarts remain using Lift 2.4. This has been done on purpouse so that different Lift quickstarts can demonstrate not only different functionality, but they can also demonstrate that Lift applications can be deployed on top of Escalante, side by side, even if they use different Lift and/or Scala versions!

  • Support for Lift applications needing Scala 2.10 has been added. In fact, Escalante is now based on Scala 2.10 and resolves other Scala version as needed depending on the deployment.

  • Escalante SBT plugin version 0.2.0 has been released with added support for Play applications to be built, deployed and run on top of Escalante. In order to avoid issues with Escalante SBT plugin, please follow the methods shown in the quickstarts on how to define the Escalante SBT plugin version to use.

  • Escalante Quickstarts have now been tagged for version 0.3.0 and the great news is two new Escalante Play Quickstarts have been added with SBT build files. Also, the SBT based quickstarts now define the Escalante SBT plugin dependency via Git URI in order to avoid the dependency resolution issue on SBT/Ivy mentioned earlier.

What's next?

In next release, Escalante will be moving to being based on top of Widlfly and both Lift and Play integrations will be further enhanced. If there's anything in particular you'd like to see done with regards to Lift or Play integration, let us know!

Get It

The simplest way to install 0.3.0 is downloading our binary distribution.

Get In Touch

If you have any questions, issues, or other feedback about Escalante, you can find us on #escalante on freenode or our public forums.


If you're interested in anything Escalante related, make sure you follow @escalanteio to find out first :). If you want to make any comments on Twitter, make sure you use the #escalante hash tag.