Originally appearing in Java Tech Journal
Interview with Gradle founder Hans Dockter
As Groovy's revolutionary build automation tool, Gradle nears a first stable version, it seemed a good time to pluck out an interview from the archives of Java Tech Journal - Tim Berglund talks to Hans Dockter about all things Gradle.
Tim Berglund: When you describe Gradle to newcomers, what do you say?
Hans Dockter: I remind them of the pain points I see in many current build systems: maintainability, performance, usability, extendability, and weak automation.
Some of those issues can affect each other in funny ways. When the build tool is really hard to extend it can have various effects. Either automation remains weak and important features do not get implemented, or automation improvements are very expensive and the maintainability costs go through the roof. In the former case, it helps maintainability by keeping the build simpler, but it prevents much automation from being implemented. Which is not a very good deal. In the latter case, automation is still weaker than it could be, and the price for improvements is very high.
Gradle does not try to fight against the natural complexity of the enterprise automation domain. There is a real maintainability cost for modeling the complexity of the domain. What Gradle works hard to avoid is additional complexity that exists merely because you have to tweak the tool. With Gradle, you only pay the price of your domain complexity, which is usually a valuable trade considering the dramatic ROI automation gives to your process. The leverage of a build is tremendous, affecting all developers and the other departments involved in the deployment pipeline.
Considering this leverage, improving build performance also has a very high ROI. This is another area where Gradle already has a lot to offer and where we will continue to deliver feature after feature. Besides all that, if your problems are simple, Gradle also keeps the solution simple. Like the best tools, it makes the impossible possible, the possible easy, and the easy elegant.
TB: What motivated you and Adam Murdoch to create Gradle when you did?
Dockter: As a software developer, I have always been very focused on improving automation in my teams. I got more and more frustrated how hard it was to implement many of the features I wanted to get done. The combination of my interest in dynamic languages, my interest in Domain Driven Design, plus my deep frustration motivated me to spike a build system based on Groovy. Pretty soon, I was sold personally on the potential of the Gradle approach and turned all my professional energy into working on it. Adam was looking for a tool to solve the build requirements of the enterprise project he was working on. He came across Gradle very early on, and his company was the first significant enterprise Gradle user. (We are talking about Gradle 0.1!) He immediately became a committer and both of us were the main forces to turn Gradle into what it is today.
TB: What are the reasons you hear most often for people adopting Gradle?
Dockter: Most often I hear people mention the ability to tailor the build to enterprise-specific standards and to introduce common lifecycles and behaviors in very heterogeneous environments. People also frequently talk about the elegance with which users can often solve non-standard build problems, the value of the incremental build, and the community.
TB: A big part of the Gradle documentation relates to its Domain Specific Language, or DSL. Why does Gradle use a DSL and not a simpler configuration file syntax?
Dockter: This relates to the Gradle toolkit approach. Gradle has basically three levels of functionality. At the bottom, there is a general-purpose execution layer based on tasks. This layer is something like Ant, but richer. Next there is a domain-specific DSL for various build domains (e.g., Java, C/C++, Docbook, etc). On top of that there is a set of opinionated smaller frameworks that provide highly functional, convention-based builds like Maven does.
This rich middle layer is one thing that makes Gradle truly unique. It provides a toolkit to easily build your own enterprise-specific, opinionated build frameworks. These can be used to replace the standard functionality of the built-in Gradle plugins, or to add entirely new ones. To tell your story with the Gradle toolkit, you need a powerful glue to put the language pieces together. This is what Groovy does for you.
TB: Right now the team is pushing hard toward a 1.0 release. After 1.0, what feature on the Gradle roadmap most excites you?
Dockter: I'm most excited about a couple of things: parallel and distributed builds and extending the domain beyond classical build topics into areas like release management and deployment.
TB: Gradle is an open-source project, but it's backed by your company, Gradleware. How is Gradleware positioned to help companies adopt Gradle and drive adoption of Gradle as an open-source tool?
Dockter: The domain of project automation and continuous delivery is a pretty new one, therefore many companies are not just having implementation issues in their automation pipeline. They are looking for guidance as to what their automation process should look like. We have a lot of experience in this strategic area and can provide a lot of help here. This is not necessarily Gradle-related, but it is expertise we have.
After providing that guidance, the next step is to implement the automation. Working in this area is often mission-critical. The leverage of a build is huge, affecting every single developer, QA professional, and release engineer. At the beginning, we can make sure that doing a migration to Gradle or implementing new features with Gradle will be successful. We pay a lot of attention that knowledge transfer is happening as part of this process. For the long term, we have support offering to help you when you run into trouble or have development questions. Recently one of our clients couldn't do an urgent release because of an upgrade to a new IBM JDK, causing the build to throw out of memory errors. We were able to figure out what the problem was in a very short time. This is for example the kind of service we can offer.
For many companies, such a commercial offering is a necessity when adopting mission-critical technologies. This serves to increase the adoption of the Gradle open source technology. Of course the income from support contracts enables us also to invest many more resources into the open source technology. It is also common that companies pay for particular open source features; for example, the C/C++ support is being funded in this way.
Last but not least, we learn a lot from being in the trenches. We gather a lot of feedback that helps us make Gradle a better tool. After all, the scale and heterogeneity of the enterprise is the real challenge for any build tool, and we want to be working closely with our community to make Gradle the best.