Let the WAR File be the Unit of Deployment

Each Java application or web server has a different way to deploy a Java web application, which is why the Cargo project exists. The same can be said of the Java PaaS solutions. (What is the Cargo of Java PaaS?)

The common unit of deployment is the WAR file. This is a good thing. Developers can use existing tools and it lowers the barrier to deployment.

A WAR file is just a standard packaging format consisting of Java classes, additional resources, plus some deployment metadata. There is no requirement that those Java classes be generated from Java source. Thus polyglot WAR deployment is possible for JVM-based languages.

CloudBees provides a number of ways for a developer to deploy a WAR file for Java or other JVM-based languages such as Clojure, Groovy, Ruby and Scala.

At the lowest level there is the HTTP API for deployment and management of applications. It’s pretty simple, but as usual with such APIs the complexity is in the authentication mechanism.

Building on the HTTP API is the CloudBees API client library, a Java library that supports the HTTP API and encapsulates the authentication details.

Building on the API client library is the Maven plugin and the Cloudbees SDK, both of which provide command line support.

Deployment flexibility at the developer’s fingertips. But, this can be taken further, integrating with other frameworks, especially those using other JVM-based languages.

For Groovy/Grails there is the Grails plugin.

For JRuby/Ruby on Rails the rails app can be packaged up as a WAR file using warbler.

For Scala/Play there is the CloudBees deployment module. There is also a plugin for Scala/SBT enabling deployment of lift applications.

Finally, and recently, for Clojure there is the lein plugin for deployment of Clojure ring applications.

Regardless of the language or Web framework all the above have two things in common: the WAR file and the JVM.