Interview with Gradle founder Hans Dockter
Tim Berglund talks to the Gradleware CEO Hans Dockter. Find out why Dockter says Gradle ‘makes the impossible possible, the possibly easy and the easy elegant’.
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
Berglund: When you describe Gradle to newcomers, what do you
Hans Dockter: I remind them of
the pain points I see in many current build systems:
maintainability, performance, usability, extendability, and weak
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
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.
motivated you and Adam Murdoch to create Gradle when you
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.
are the reasons you hear most often for people adopting
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
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
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
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.