Interview with Hans Dockter: Gradle, Android, and DevOps
Here's a recent interview with Hans Dockter, founder of Gradle and Gradleware. We talked about the new Android plugin, and Gradleware's conference on June 13-14th in Santa Clara: Gradle Summit 2013 .
Q: Gradleware recently announced that it was creating an Android plugin for Gradle What made you decide that Android was the right target for Gradle?
Hans Dockter: The great thing about collaborating with open source projects is that there are few secrets. Everything is done out in the open. So, for those of you who are paying attention to the Android Tools project it will come as no surprise that the Android Tools team has been working very closely with Gradleware on the next-generation Android build tool. Gradleware didn’t make a decision to target Android as much as the Android Tools team made a decision to use Gradle.
We’ve been working with Xavier Ducrohet of Google who has been driving the effort to develop an Android plugin that will give developers a very efficient way to create declarative Android builds. The new build system is still in development, but you can use it today. Every new release of Gradle includes core improvements driven by the needs of the Android Tools project, and we’re pretty excited about this effort.
This Gradle Android plugin is the first time we’ve seen a build system designed specifically for mobile development. There are some new concepts and approaches that are unique to the space. We’ll be at Google I/O demonstrating the plugin next month, and this is a major focus for us in June.
Q: What do you mean by “unique to the space”? What’s makes and Android build different from a more traditional Java build?
Hans Dockter: Think about the mobile applications you use, and you’ll see that mobile applications are about variations. Take a game like Angry Birds or Cut the Rope as an example. Angry Birds runs on android devices, it runs on every phone and tablet I own so it has to support an array of devices, and not all of these devices are phones. The opportunity for the next few years will be applications that span multiple screens and devices.
This means that there are likely customizations for different device dimensions, different device processor architectures, different gestures for wearable devices, and a few other important variables. On top of that Angry Birds has several variations. There is a Star Wars version and a Christmas version and several other versions I don’t even know about. If you are a consumer of mobile applications you understand that the best applications are the ones that cater to each device, each platform.
Add to this the complexity of having multiple product “flavors” - a free version vs. a paid version, and you have this Cartesian "explosion" of build variation to manage. You can’t just have a single build for these projects, you have to have a build that can support the entire set of possible build variants. To me, this is the most compelling feature of the Gradle Android plugin. The Android Tools team worked with us to create a build system that addressed these requirements with a simple, declarative syntax.
We call it a Domain-specific Language a DSL, but I’ve been told to avoid this term as it scares people away. Really what they did was create a system that can support the 60+ variations of a mobile application with a simple Gradle build that doesn’t require a PhD in Build Systems. Solve the problem in thirty lines of configuration instead of having sixty projects.
Besides this there are other very important aspects why Google’s Android team went with Gradle: performance, dependency management, deep IDE integration, and customizability. Gradleware will be talking more about this on our blog in the next few weeks.
Q: Android already has a Maven plugin available, what makes this Android plugin different?
Hans Dockter: I don’t want to get into the “horse race” between Gradle and Maven. I’ve done that already. I’ve talked to the people behind the Maven Android plugin and they are good people, but we’re doing things in the Gradle Android plugin that are just impossible to do in Maven. Understandably, I haven’t spent too much time with Maven in the last few months as I’m focused on something different.
What you’ll get with Gradle is an “official” build tool for Android that will be supported by the Android Tools project. There are some very unique requirements for Android builds that conflict with basic design of Maven: the POM and the inflexible conventions it presents. Even at this early stage, the Android builds that are possible with Gradle present a much simpler interface than the equivalent Maven build. Just take product flavors and build variants as one example, you can’t do this in Maven without subjecting yourself to unsafe levels of exposure to XML.
Again, I really don’t want the story to be about Gradle vs. Maven, but I am confident that, in a year’s time, most Android developers will consider Gradle to be the build tool of choice because that’s what has happened, the Android Tools team has selected Gradle. Maven’s approach doesn’t scale and the existing Maven-based approaches to Android builds don't take into account some of the approaching changes. I’ll have more to say on this later.
Q: The build automation space has seen some activity of late. Urbancode and Nolio were both acquired. How is this affecting Gradleware?
Hans Dockter: Well, it’s very interesting to me. Gradleware has been around for a number of years, and, at the beginning of this company I had quite a few people tell me that there was little money to be found in ”build tools”. That was four years ago.
We’re still a company focused on our immediate goals of making Gradle the best build and automation platform available and growing the company organically, so it isn’t like we’re focused on news of acquisitions. That being said, when I heard this news it was another data point to suggest that the industry is finally starting to pay attention to this space. Builds are the source of such pain for these large enterprises and most developers have just grown accustomed to dysfunction. The right people are starting to realize that the status quo isn’t working.
One thing I’m not so sure about is how these companies are positioned as “DevOps” companies. This term is so overloaded, so full of implicit meaning, and there is little agreement on what it means. I tend to avoid it because half the time people think that Gradle is a Puppet or Chef alternative.
Q: Well is it? Couldn’t you use Gradle to do similar things?
Hans Dockter: No. Although there is a bit of overlap, it is not our focus. We’re focused on building and testing applications and automating deployments, we’re not going to be building a system to manage infrastructure at the operating system level. We could, and some people have tried to extend Gradle and create plugins that take on operational responsibilities, but this isn’t the problem begging to be solved. None of our customers come to us asking for this. Instead, they ask us to help them with the release process, build standardization, advanced dependency management, complex testing scenarios, reproducibility, and developer efficiency.
Gradle isn’t aiming to manage infrastructure but there is a huge potential for integrating Gradle with tools like Chef and Puppet. This old model of developers throwing binaries over a wall at operations is over.
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)