Monthly Archives: September 2015

Scala Spray Can using Gradle with Cloud foundry and the java buildpack

What we are trying to do

Use gradle to build and package our app. We are using gradle as our build tool as we did not like the Sbt way of doing things.

Deploy a single self contained running Spray application with all required runtimes dependency on Cloud Foundry as a java application.

If possible get off using our self written wrapper java tools to deploy and manipulate Cloud Foundry using the cloud foundry jar.


We were trying out different gradle plugins to try and get our Spray app deployed.  We had settled on oneJar as there was documentation of people using it with gradle to create and run a self contained file.


The oneJar plugin changes the class loader to accept self contained single file that is a jar with jars inside it.

Messing around with class loading means you are going to have a bad time.

An idea from Spring Boot deployment

Chatting with some other devs I was also explaining we had problems deploying our Spring boot app, so were prevented from deploying onto our latest and greatest Cloud Foundry instance.  We have hard gained experience on out how to deploy our apps on an older version of CF but it never started properly on the new CF.  I was pointed to this by another developer as to how to deploy a Spring Boot application properly from the java buildpack documentation.

Cloud Foundry docs for Spring boot deployment

DistZip to the Rescue

This got me thinking of how Spring boot uses the distZip style deployment and could I leverage it to deploy my Spray app. Spring boot uses the distZip which comes from the  application gradle plugin.

What distZip does

Creates a zip file with all the runtimes needed your application with the correct  META-INF/MANIFEST.MF info and a start script to run it.  Cloud Foundry is happy to deploy this.

You will need to set your main class to tell distZip what to run

mainClassName = "org.gradle.sample.Main"


On Cloud Foundry the application needs to bind to a port provided on deployment time to accept connections, else CF will not let it succeed in starting and kill it.

Here is a code snippet of what it takes to bind the Spray to CF.

import com.typesafe.config._

val envConf: Config = ConfigFactory.systemEnvironment()
def serverPort = envConf.getInt("VCAP_APP_PORT")

 IO(Http) ? Http.Bind(actorSystem.actorOf(Props(wire[YourActor]), "your-actor"), interface = "", port = serverPort)

Using the Cloud Foundry Gradle Plugin

After getting a successful deployment using the command line tool(CLI) I was then able to use the Gradle CF plugin to configure and deploy.  This makes it easier for Jenkins as we do not have to change our build slaves to deploy the CLI and change our chef scripts for build slaves.

Docs for CF gradle plugin

Setup snippet

cloudfoundry {
    target = ""
    space = "snapshot-YOURS"
    file = file("./build/distributions/")
    buildpack = ""
    application = "YOUR_APP_NAME-dev"
    trustSelfSignedCerts = true // needed for our managed instance
    memory = 1024
    instances = 2
    env = ["SPRING_PROFILES_ACTIVE": "A_PROFILE"]  //we are using the spring boot style way of dealing with different properties files for different enviornments.

CF Commands

It is a bad idea to hold the credentials in your source control system. so you or your build slave  should login and out using secured credentials.

  1. gradle cfLogin -PcfUsername=’your-user-name’ -PcfPassword=’your-password’  -PcfOrganization=’your-organisation’

With the above snippet the target, space, buildpack, file and application name you can just do a push without any additional commands.

2. gradle cfPush

Different Environments

Just override the needed elements to deploy to new environments with -PcfThingToOverride=’NEW_VALUE’


gradle cfPush -PcfTarget=’; -PcfSpace=’stage-space’ -PcfInstances=’4′ -PcfApplication=’YOUR_APP-stage’ ….