JVM Languages

Why Build Your Java Projects with Gradle Rather than Ant or Maven?

By Benjamin Muschko, July 08, 2014

The default build tool for Android (and the new star of build tools on the JVM) is designed to ease scripting of complex, multi-language builds. Should you change to it, though, if you're using Ant or Maven?

Effortless Extendibility

Most enterprise builds are not alike, nor do they solve the same problems. Once you're past the initial phase of setting up
your basic scripts, you'll want to implement custom logic. Gradle is not opinionated about the way you implement that code.
Instead, it gives you various choices to pick from, depending on your specific use case. The easiest way to implement custom
logic is by writing a task. Tasks can be defined directly in your build script without special ceremony. If you feel like
complexity takes over, you may want to explore the option of a custom task that allows for writing your logic within a class
definition, making structuring your code easy and maintainable. If you want to share reusable code among builds and projects,
plugins are your best friend. Representing Gradle's most powerful extension mechanism, plugins give you full access to Gradle's
API and can be written, tested, and distributed like any other piece of software. Writing a plugin is surprisingly easy and
doesn't require a lot of additional descriptors.

Integration with Other Build Tools

Gradle plays well with its predecessors Ant, Maven, and Ivy, as shown in Figure 6.

If you're coming from Ant, Gradle doesn't force you to migrate your full build infrastructure. Instead, it allows you to
import existing build logic and reuse standard Ant tasks. Gradle builds are 100% compatible with Maven and Ivy repositories.
You can retrieve dependencies and publish your own artifacts. Gradle provides a converter for existing Maven builds that can
translate the build logic into a Gradle build script.

Existing Ant scripts can be imported into a Gradle build seamlessly and used as you'd use any other external Gradle script.
Ant targets directly map to Gradle tasks at runtime. Gradle ships with the Ant libraries and exposes a helper class to your
scripts called AntBuilder, which fully blends into Gradle's DSL. It still looks and feels like Ant's XML, but without the pointy brackets. Ant users
will feel right at home, because they don't have to transition to Gradle syntax right away. Migrating from Ant to Gradle is
also a no-brainer. You can take baby steps by reusing your existing Ant logic while using Gradle's benefits at the same time.

Gradle aims to reach a similar depth of integration with Maven. At the time of writing, this hasn't been realized yet. In
the long run, Maven POMs and plugins will be treated as Gradle natives. Maven and Ivy repositories have become an important
part of today's build infrastructure. Imagine a world without Maven Central to help access specific versions of your favorite
project dependencies. Retrieving dependencies from a repository is only one part of the story; publishing to them is just
as important. With a little configuration, Gradle can upload your project's artifact for company-wide or public consumption.

Community-driven and Company-backed

Gradle is free to use and ships with the Apache License 2.0. After its first release in April 2008, a vibrant community quickly
started to form around it. Over the past five years, open source developers have made major contributions to Gradle's core
code base. Being hosted on GitHub turned out to be very beneficial to Gradle. Code changes can be submitted as pull requests
and undergo a close review process by the core committers before making it into the code base. If you're coming from other
build tools like Maven, you may be used to a wide range of reusable plugins. Apart from the standard plugins shipped with
the runtime, the Gradle community releases new functionality frequently. Every community-driven software project needs a forum
to get immediate questions answered. Gradle connects with the community through the Gradle forum.
In addition, there's a commercial company, Gradeleware, that supports the product.

Additional Useful Features

Gradle is equipped with a rich command-line interface. Using command-line options, you can control everything from specifying
the log level, to excluding tests, to displaying help messages. This is nothing special; other tools provide that, too. Some
of the features stand out, though. Gradle allows for running commands in an abbreviated, camel-cased form. In practice, a
command named runMyAwesomeTask would be callable with the abbreviation rMAT. Even
though I present most of next week's examples by them running commands in a shell, bear in mind that Gradle
provides an out-of-the-box graphical user interface.

The Bigger Picture: Continuous Delivery

Being able to build your source code is only one aspect of the software delivery process. More importantly, you want to release
your product to a production environment to deliver business value. Along the way, you want to run tests, build the distribution,
analyze the code for quality-control purposes, potentially provision a target environment, and deploy to it.

There are many benefits to automating the whole process. First and foremost, delivering software manually is slow, error-prone,
and nerve-wracking. I'm sure every one of us hates the long nights due to a deployment gone wrong. With the rise of agile
methodologies, development teams are able to deliver software faster. Release cycles of two or three weeks have become the
norm. Many organizations now even ship code to production several times a day! Optimally, you want to be
able to release software by selecting the target environment simply by pressing a button. Practices like automated testing,
CI, and deployment feed into the general concept of continuous delivery.

Let's look at how Gradle can help get your project from build to deployment. It can enable you to automate many
of the tasks required to implement continuous delivery, be they compiling your source code, deploying a deliverable, or calling
external tools that help you with implementing the process. For a deep dive on continuous delivery and all of its aspects,
I recommend the Jolt Award-winning Continuous Delivery
by Jez Humble and David Farley.

Automating Your Project from Build to Deployment

Continuous delivery introduces the concept of a deployment pipeline, also referred to as the build pipeline. A deployment
pipeline represents the technical implementation of the process for getting software from version control into your production
environment. The process consists of multiple stages, as shown in Figure 7.

Figure 7: Stages of a deployment pipeline.

Commit stage: Reports on the technical health level of your project. The main stakeholder of this phase is the development team as it provides
feedback about broken code and finds "code smells." The job of this stage is to compile the code, run tests, perform code
analysis, and prepare the distribution.

Manual test stage: Verifies that the system is actually usable in a test environment. Usually, this stage involves QA personnel to verify requirements
on the level of user stories or use cases.

Release stage: Either delivers the software to the end user as a packaged distribution or deploys it to the production environment.

Let's see what stages of the deployment pipeline can benefit from project automation. It's obvious that the manual test stage
can be excluded from further discussion, because it only involves manual tasks. The concrete tasks we're interested in are:

Compiling the code

Running unit and integration tests

Performing static code analysis and generating test coverage

Creating the distribution

Provisioning the target environment

Deploying the deliverable

Performing smoke and automated functional tests

Figure 8 shows the order of tasks within each of the stages. While there are no hard rules that prevent you from skipping specific
tasks, it's recommended that you follow the order. For example, you could decide to compile your code, create the distribution,
and deploy it to your target environment without running any tests or static code analysis. However, doing so increases the
risk of undetected code defects and poor code quality.

Figure 8: Tasks performed in stages of build pipeline.

Topics such as infrastructure provisioning, automated deployment, and smoke testing can also be applied to the release stage.
In practice, applying these techniques to a production environment is more complex than in a controlled test environment.
In a production environment, you may have to deal with clustered and distributed server infrastructures, zero-downtime release
rollouts, and automated rollbacks to the previous release.

Covering these advanced topics would go beyond the scope of this series. However, there are some great examples of deployment
management tools in the wild that you may want to check out, such as Asgard,
a Web-based cloud management and deployment tool built and used by Netflix. But enough pure theory  in the follow-up article next week,
I'll discuss installing Gradle on your machine and building your first project.

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task.
However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

Video

This month's Dr. Dobb's Journal

This month,
Dr. Dobb's Journal is devoted to mobile programming. We introduce you to Apple's new Swift programming language, discuss the perils of being the third-most-popular mobile platform, revisit SQLite on Android
, and much more!