Let the WAR File be the Unit of Deployment

Cargo of Java PaaS
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.


Paul Sandoz


The Babel Fish image is a trademark of Yahoo! Other product or brand names may be trademarks or registered trademarks of their respective holders.



That's just plain wrong. http://www.slideshare.net/actionjackx/automated-java-deployments-with-rpm. And feel free to replace rpm with any other operating system level package.

Why any Java developer should want to build RPM's is beyond me. Slide #4 of the above linked presentation is why we should use a PaaS, not why we should learn to write RPM spec files.

Kris - I think you kind of missed the target of this blog - this is all in the context of a PaaS - behind the scenes there are package systems going on (arch linux, RPM and even .debs in places are actually being used) - this is more the front end of things - specifically for a paas. If it wasn't for a PaaS - I would definitely want to use a package system - it certainly wouldn't be RPM - it is possibly the least pleasant way to package software (great presentation - would be much nicer with another package manager !) - replace it with debs or perhaps pacman/arch (my personal fav.) and I am with you all the way.