Quick and dirty Gradle task for deploying Cloud Foundry

gistfile1.txt

buildscript {
  repositories {
    mavenCentral()
    maven { url 'http://maven.springframework.org/milestone' }
  }
  dependencies {
    classpath 'org.cloudfoundry:cloudfoundry-client-lib:0.7.1'
  }
}

import org.cloudfoundry.client.lib.CloudApplication
import org.cloudfoundry.client.lib.CloudFoundryClient

task cloudFoundryDeploy {
  dependsOn assemble
  inputs.dir "$project.buildDir/libs"
  doLast {
    String target = System.properties['vcap.target']
    String email = System.properties['vcap.email']
    String passwd = System.properties['vcap.passwd']
    if (!(target && email && passwd)) {
      throw new GradleException("'vcap.target', 'vcap.email' and 'vcap.passwd' system properties are required for the cloudFoundryDeploy task")
    }
    String appName = project.name
    String url = target.replaceFirst(/^api\./, "${appName}.")
    CloudFoundryClient client = new CloudFoundryClient(email, passwd, "http://$target")
    client.login()
    if (client.getApplications().find { it.name == appName }) {
      client.stopApplication(appName)
    }
    else {
      client.createApplication(appName, CloudApplication.SPRING, client.getDefaultApplicationMemory(CloudApplication.SPRING), [url], null);
    }
    client.uploadApplication(appName, file("$project.buildDir/libs/${project.name}.war"))
    client.startApplication(appName)
  }
}

Consider doing all of the following outside of (above) the doLast { ... } block:

String target = System.properties['vcap.target']
String email = System.properties['vcap.email']
String passwd = System.properties['vcap.passwd']
if (!(target && email && passwd)) {
  throw new GradleException("'vcap.target', 'vcap.email' and 'vcap.passwd' system properties are required for the cloudFoundryDeploy task")
}
String appName = project.name
String url = target.replaceFirst(/^api\./, "${appName}.")

This allows these statements to be evaluated during the building of the task graph, allowing for fail-fast behavior if something is wrong, e.g. a property has not been specified. Otherwise the user will have to wait for all dependent tasks to execute before getting to the cloudFoundryDeploy task's doLast block, only to find it failing.

It's somewhat more idiomatic Gradle to write

task cloudFoundryDeploy(dependsOn: assemble) { ... }

than it is to write

task cloudFoundryDeploy {
    dependsOn assemble
}

They are functionally equivalent, the former just emphasizes task dependencies more prominently, and is more concise to boot.

Minor point here, but it's more Groovy-ish to drop the explicit typing, e.g.:

String appName = project.name

becomes

def appName = project.name

Note that the way this works in Gradle is that if the variable is a def, it is task-local, whereas if it is declared simply as

appName = project.name

then it becomes a publicly-visible property of the task. This can be quite useful in cases where you want to refer to this information from another task, e.g.:

task myOtherTask {
    println cloudFoundryDeploy.appName
}

Note that there is now a clear path for creating and publishing Gradle plugins to the SpringSource repository (http://repo.springsource.org). Take a look at https://github.com/springsource/gradle-plugins for examples/inspiration if you'd eventually like to turn this gist into a proper plugin.

As of this writing the gradle-plugins project is lacking documentation, but I'm happy to help in the meantime.