We managed to squeeze in an exclusive interview with Hans Dockter the founder and project lead of the Gradle build system and the CEO of Gradleware Inc ahead of his Keynote talk at the Gradle eXchange 2013. Read on to get a sneaky insight into what Hans will be sharing at Gradle!
1. How did you come up with Gradle? Is it true that it was at a Skills Matter conference where the idea for Gradle crystallised?
As I started using Groovy as a technology for my initial build system spikes I thought it would be a good idea to attend the first ever Groovy and Grails Exchange. There I met Steven Devijer, the co-founder of Grails, who was also doing some work on an internal build tool for his client. We both got very excited at this point about pushing a new build system forward.
So, yes, the first Groovy and Grails eXchange played an important part. The discussions and the interactions at that Skills Matter conference helped get some of the ideas I had been working on, and I was able to connect with like-minded developers.
2. Hans can you tell us, in your words, what Gradle was, what it is now and where it is going?
Gradle was, always has been, and always will be our idea for a more efficient continuous delivery tool. Some people might call it a build tool, and eventually others may only interact with it via an IDE, but at the foundation Gradle is exactly what it was when I started the project almost six years ago.
The only thing that’s changed with Gradle is the scale of the requirements and now the ambition of our team and our community. As for where Gradle is going? I’d like to see us focus on efficiency across the board. This isn’t just about faster or more efficient builds and the ability to customize your build to suit your requirements. We’re attacking some of the fundamental inefficiencies in the IT department.
How large teams integrate several projects into a final deliverable is something that is fraught with problems. Go look at any large team and you’ll see that the build and delivery part of the application life-cycle is typically done in a haphazard way: there’s no communication between teams, there’s lots of waiting involve in any enterprise release process. We’d like to take Gradle’s ideas of declarative efficiency and flexibility and apply them to all languages. We’d like to get more involved in application deployment and finally allow people to be able to have that full life-cycle connection between developers and the systems that are deployed to production.
Also, if you want to see where Gradle is going watch the Android work we’ve been doing. Google’s involvement with the new Gradle-based Android build system was a dramatic “accelerant” for the community. We’ve made more progress in the last year than I anticipated we’d make in five, and the pace continues.
3. Besides the no lock-in with the Gradle Build System – what are the key advantages over other build systems?
It’s as flexible as you need it to be, but it also gives the ability to enforce standards. That sounds easy, right? It’s the “best of both worlds”, but behind the scenes there’s a lot of things we’ve done to strike the right balance between flexibility and standardisation.
It would maybe take too long to run through a full explanation, but the key advantage in Gradle is that you have this ability to have a high-level structure for your build. If you are building an Android application, you apply the Android plug-in and this brings a lot of structure and re-usability with it. So much structure that if your build fits the standards defined in Android you can have a complex project generate 32 variants for different platforms, run a series of complex build steps, and work with a 10-20 line build file.
If on the other hand, you have a requirement that calls for customization, your build can take that Android plug-in and customize it at all levels. You can customize not only what each step does but you can add in new steps. It’s a tough thing to explain to someone who has experienced multiple build systems, but when you customise Gradle you don’t feel like you are fighting it. That’s probably the biggest difference between Gradle and the alternatives – we acknowledge that you are going to have unique requirements.
4. We’re sure you’ve been asked many times but why is Groovy your language of choice?
Groovy is a great language, we`re happy that we decided to use Groovy as the language of build.gradle files, but there`s a misconception in this space. 90% of Gradle is written in Java, and I want to emphasize that because people tend to think that Gradle is only for Groovy projects. It certainly isn’t. We chose Groovy for the build script language because it is extensible, because it supports closures, because it is dynamic, and because it is tightly integrated with Java. We certainly weren`t going to use XML.
But, again, I’d like to emphasize, Gradle “uses” Groovy, but it is mostly written in Java and we support many languages including C, Assembler and C++. That being said, Groovy was a great choice for us, also because it has such a great community.
5. Are you still a fan of DDD (Domain Driven Design)? How does this fit with the Gradle build system?
Yes, of course. Domain Driven Design is at the core of what we do. In Domain Driven Design you have the Domain, the Model, a “Ubiquitous Language”, and a shared Context. When we tackle a new language or a new platform. When we add support for a new system we analyse it from the perspective of DDD.
Let’s take Android as an example, and let’s assume that we were not using Gradle.
Let’s assume we were using Maven as a build tool for Android. Maven doesn’t lend itself to Domain Driven Design because it has a very inflexible model and a lifecycle that is set in stone. Even though Android calls for build types, build flavors, and, in general, a lot of build variation, you can’t really model that in Maven. Maven, in other words, forces you to model a build on Maven’s terms. In Gradle, we’ve created a platform that allows people to use a model, a ubiquitous language, and a context that has been tailored to fit a specific language or platform. In Android’s case, you can use the Gradle-based Android build tool that Google and Gradleware developed in tandem to create a build that configures a complex Android build efficiently. We’re not going to force your language or your platform to adhere to our domain. No, on the contrary, we’ve created a platform that lends itself to your domain and which can adapt to your domain’s specific requirements.
This isn’t just about new languages or a new platform. Again, our customers are the largest companies in the world and they often come to us with a well established domain. We’re not going to tell the largest manufacturer in Europe that they need to adapt to our tool. Instead we’re going to understand that domain, and create a system that caters to their requirements. So, short answer, is yes. Gradle is Domain-driven Design.
6.What three key things do you hope people will take away from the Gradle eXchange?
We are making enormous investments in the core of Gradle and preparing for a 2.0 release. That Gradle is very much ready to help solve your build and continuous delivery problems. And that we’re always looking for input and involvement. Gradleware is busy building a community, we’re still at the beginning of this story and we’re looking for all the help we can get.
7.Can you give us a sneak preview of any announcements you’ll be giving?
We are practising continuous delivery, we are not doing “Big Bang” releases. As we release every 6-8 weeks, the Gradle that is released is never that far away from the Gradle that is in development and new features are rolled out incrementally. Therefore we won’t announce any new big available feature.
In my keynote I will talk about the big things we will focus on in the next 12 months.
- Dependency Management
8. Who are you looking forward to learning from and sharing skills with at Gradle eXchange – apart from all the delegates that is!
You’ve seen me at these conferences, right? I don’t go to these conferences to present as much as I go to discuss new features with my colleagues. This isn’t to say that I’m not excited about presenting: I am, but I’m also very keen on sitting down with colleagues, customers, and community members to look at real builds and real requirements. I get very animated about this domain, and I come away from every conference excited about the ideas and possibilities created by in-person collaboration.
Every conference I go to, it’s always the conversations between the sessions and the people that I get a chance to talk to that bring the most value for me. We’re in this amazing stage of development where there is so much to do and so many ideas to discuss. For me, conferences are primarily about these discussions, and I have to tell you that it’s both exciting and somewhat exhausting. Come to Gradle eXchange and you’ll see how much energy our team puts into Gradle not just in terms of coding but in terms of building the community. I’m excited.
9. What will be the next big thing in the tech world?
We see it everywhere – a focus on efficiency and faster time-to-market. That’s a constant, taking a macroeconomic perspective the current focus on efficiency is driven by increasing competition across all markets. As we continue to connect more of the world to the internet, the world is shrinking a bit and everything is moving faster. So for us, it means that a lot of companies are coming to us telling us that they can’t afford to sacrifice a month or two a year to the build. Our customers are looking to save time everywhere they can because an efficient continuous delivery pipeline is now seen as a competitive advantage.
Earlier I mentioned that the last half of the last decade was all about dynamic languages challenging static languages.
You can see that the world has evolved to an interesting place. You’ve got teams at Facebook developing systems in PHP, yet Facebook also does a lot of development in Java. It doesn’t matter what industry you are in, we’re seeing a lot of companies taking a multi-language approach to architecture, and this can cause enormous headaches for build and delivery. Whether you are dealing with the intersection of Scala and Java or the intersection of Java with Native applications. We’re seeing this as a new trend. Customers are no longer happy maintaining heterogeneous builds in separate build systems.
So, you ask for one “next big thing”, and I gave you two: continued focus on faster development life-cycles and a focus on supporting diverse builds.
The Gradle eXchange 2013
Ever wondered where Gradle is heading or the role it has in the current market? Are you interested in finding out the latest and greatest from Hans Dockter, creator of Gradle? Or just wanting to share your project successes or pains within the Gradle community?
Join Adam Murdoch (co-founder of Gradleware), Luke Daley (principal engineer at Gradleware), and Szczepan Faber (principal engineer at Gradleware) as well as many other Gradle experts and committors to better your understanding of how Gradle can be used in within your projects now and what it can do for you in the future!
Still considering whether to introduce Gradle to your projects?
Get together with a passionate community of Gradle enthusiasts throughout the day and find out how other companies, like Novoda, have benefited from adopting Gradle, while understanding what worked or what didn’t for them, in the highly anticipated park bench discussion!