A Slice of Groovy’s Hip Use of JFrog Artifactory & Bintray, and of Gradle and TeamCity

Grrroooooovy, Baby!

Groovy supporters describe the Groovy programming language as dynamic and statically typed, supporting functional programming and OOP as a superset that includes the Java programming language. “It’s a kind of Java on steroids if you will!” says Guillaume Laforge, an Apache Groovy project PPMC member. A few examples of common applications of Groovy will help to illustrate its position in the programming landscape.

Developers use Groovy in the build and test phases of a variety of projects even though they did not code their applications in Groovy. Coders find Groovy an inviting language for writing and maintaining tests due to its reader-friendly concision. “Developers use Groovy with the Spock Framework for unit testing and behavior-driven development and with Geb for Web integration testing,” says Laforge.

Programmers use Groovy scripts for application extensibility for integration, configuration, customizations, and plug-ins. “The Jenkins Build Flow plug-in is a prime example as it enables users to orchestrate jobs by using the Groovy language to extract those jobs’ flow logic,” says Laforge. Other uses for Groovy include domain-specific languages, administration, automation, and Web, desktop, and mobile application development.

DevOps.com explores elements of Groovy’s trip from manual to automated development.

Manual Processes, Not So Groovy

When the developers of the Groovy language released software from individual developer machines and using other manual processes, this created several issues. If a developer neglected to give birth to a dedicated release branch, this could equate to non-committed files and local changes transferring directly into the release prior to joining the mainline source tree, skirting prudent source control requirements.

“Or we could simply forget to set tags for releases or we could commit errant version number data,” says Laforge; “although the release’s version is x.y.z., the version in the manifest would be x.y.w.”

In some cases with individual developer machines, new developers would experience discrepancies. For example, a new developer performing a project build could see dependency-related challenges such as when one project depends on another that has corrupted “pom” (Project Object Model) files. “Local repositories would fill up with odd dependencies,” says Laforge. There were other issues, as well.

Groovy Fully Automates Its Release Process

One of the progressions that Groovy made toward automated bliss was in the realm of version control. Groovy eventually moved from CVS to Subversion to Git and from Codehause to Github as its repository. “More recently, we moved the sources to Apache’s Git, as Groovy entered the Apache Software Foundation incubation process,” says Laforge.

Today, Groovy developers send snapshots to the JFrog open source Maven repository, Artifactory, to test their bug fixes and features. According to Laforge, Groovy applies the JetBrains TeamCity CI server to build artifacts and distributions; the Artifactory plug-in for TeamCity enables Groovy to stage releases using Artifactory. Artifactory and Bintray integration enables Groovy to push everything to Bintray. Dependency management occurs on Bintray’s JCenter Maven repository. Synchronization with Maven Central supports developers who are retrieving dependencies.

The Gradle build automation tool supports a mature build setup for Groovy, allowing the language developer to bootstrap its own compiler, enabling it to build Groovy code. “This is part of our deliverable, i.e., Groovy basically compiling itself,” says Laforge; “this would be much more difficult using other build solutions.”

Drilling down, there are more benefits to having Gradle and TeamCity working in tandem. For one, it affords Groovy the opportunity to test different flavors and functionalities of Groovy on different platforms and environments. “We can do this using different JDK versions from 6 up to the as yet unreleased ver. 9, testing against our own snapshots and using different flags for testing and building Groovy with or without the invoke dynamic support from JDK 7 onward, with different branches,” says Laforge.

Reinstituting Manual Processes for Apache

On entering the Apache Software Foundation, Groovy had to re-introduce manual steps in order meet Apache guidelines that state that Apache committers must build projects themselves and that they need to sign their deliverables with their own keys. “We are still using Gradle, JetBrains Team City, and JFrog Artifactory and Bintray, but not in as much an automated fashion as before,” says Laforge.