A promise to hit the sweet spot

 

The Gradle build system promises to hit the sweet spot between Ant and Maven. It allows for convention over configuration build scripts (lesser code). The build scripts are highly readable and compact compared to its XML based cousins (looking at you Ant and Maven) thanks to its own groovy based DSL (domain specific language) . 

Consistent and (fail-) fast builds are a key component to any successful Continuous Integration / Continuous Deployment (delivery) – process (from now on CI/CD). The build in itself is one of the most important parts of a modern CI solution. Gradle integrates well with Jenkins and Artifactory (binary storage). In a previous assignment I was tasked with replacing the old build system (Ant based), having worked with Gradle in the mobile world I began a journey to convert the old build to a new based on Gradle. The project to build was a Java EE application with several sub modules, here are the key points on why specifically Gradle was chosen:

cropped-flower.png Incremental build support (Gradle only builds files that has changed), checksums everything (both input and output files)
cropped-flower.png Parallel builds, Gradle utilizes all your cores if you have several Gradle sub-projects to build
cropped-flower.png Gradle has a daemon (a JVM running ready to build instantly), default enabled in Gradle 3
cropped-flower.png Fails fast (trust me it’s a good thing!). Builds are separated into three phases init, config and execute phases.
cropped-flower.png Groovy scripting support
cropped-flower.png Kotlin scripting support (as of Gradle 3.0), enables autocomplete for your build scripts in e.g. IntelliJ
cropped-flower.png Compact DSL: easy dependency declaration, a dependency needs one row of declaration
cropped-flower.png Support running Ant tasks from within Gradle (great for complicated legacy tasks from e.g. Ant, enables gradually rewrite of legacy tasks)
cropped-flower.png Debugging / profiling support, you can get a html report of where your build time is spent in the build process and also since Gradle runs in a JVM you can attach a debugger to the Gradle process itself
cropped-flower.png In a future release (targeted for 4.0, in 2017) there are plans for a distributed build cache. This means that same commit (branch) needs only to be built once and for any subsequent builds the artifacts can be fetched from the cache.
 

animation
Gradle builds in action showing the powerful up to date checks that’s builtin in the tool

 

Part of the old Ant build was a JAXB generating task, converts XML schema definitions files to Java files that later consumes data (XML) to generate reports. The declaration in Ant for this was around 400 lines (most parts was specifying which XSD files to use while generating the Java ones). Four different modules were using the same JAXB generating code, which led me to the idea of reusing the code for generating the java files through JAXB. This is where Gradle plugins come in handy, since it promotes reusability and with Gradle’s powerful configuration injection makes the whole process a breeze. A complete rewrite of this part of the Ant build script was not planned.

A COMPLETE GRADLE PLUGIN 

Below you’ll find the complete Gradle plugin for generating java files from xsd files. All the interesting stuff happens in the convert method. Most important is the call to project.ant here Gradle delegates a call to the Gradle built in Ant runtime with the XJC task target that takes in all the different parameters we set with the definitions inside BaseTask class, we set the parameters from the dynamically generated Gradle tasks, see later code snippet. 

To use the above plugin in your Gradle build you need the following lines in your script: 

An array with holder data, example of one element:


Magnus  Borgström : Senior Consultant

Magnus Borgström
Senior Consultant
+46 73 060 87 86
magnus.borgstrom@itinforma.se

Magnus has extensive technical experience as a developer and software architect for large mission critical systems. He is responsible for designing and developing applications in multi-layered architecture. The solutions put high demands for scalability to handle high performance standards, and usability.

Magnus is creative, versatile and easy to adapt to different methodologies and technologies. He has a good ability to understand customer needs and requirements. Magnus' perseverance and curiosity are prominent features in his personality which often appear / are evident in his manner of tackling challenges.



Please feel free to share