Gradle

Many developers were burned by the overly complex world of Java back in the early 2000s. The Gang of Four patterns and middleware / J2EE / Java EE led to ridiculous levels of alleged decoupling as is evident in this sequence diagram from an open source J2EE ecommerce system I worked on in 2002:

Back in 2014 I wrote about how things had changed: Java Doesn’t Suck – You’re Just Using it Wrong.  But six years have passed since I wrote that and things have continued to improve, making the Java platform a fantastic option when building microservices, data pipelines, web apps, mobile apps, and more.  Let’s walk through some of the “modern” (as of 2021) aspects to the Java platform.

As part of the Salesforce Wear Developer Pack for Android Wear I created a Gradle plugin that fetches and deploys Salesforce code (Apex). Gradle is the default build tool for Android but it can also be used with many other languages. For instance, here is an example build.gradle file for a project that fetches all of the Apex classes and Visualforce pages:

buildscript {
    repositories {
        mavenLocal()
        mavenCentral()
    }
    dependencies {
        classpath 'com.jamesward:force-gradle-plugin:0.1'
    }
}

apply plugin: 'force'

repositories {
    mavenLocal()
    mavenCentral()
}

force {
    username = forceUsername
    password = forcePassword
    unpackagedComponents = ["ApexPage": "*", "ApexClass": "*"]
}

The unpackagedComponents definition uses the Salesforce Metadata Types and pulls everything specified down into the src/main/salesforce/unpackaged directory when you run the forceMetadataFetch Gradle task. The forceMetadataDeploy Gradle task deploys everything in the src/main/salesforce/unpackaged directory to Salesforce.