Top 5 Reasons Gradle Should Be Your Build Tool of Choice
Gradle isn’t the same as it use to be, now being more mainstream, but at one time back in 2008 it was a brand new beast. But lots of things that were cool then are still cool now *wink*. Since Gradle is so near and dear to us, we figured we’d share with you the top five reasons why you should consider it as your build tool of choice. Below we have included both the video and the slides from this tech talk, as well as a few main takeaways below the video to help you along the way.
Gradle: From Extreme to Mainstream Tech Talk Video
If you want to see the entire presentation, click on the slides below.
5 Reasons Gradle Should Be Your Build Tool of Choice
1. You don’t have to install Gradle…
Assuming you have someone who knows what they are doing. Alright, so someone has to install Gradle. For the person installing it, there’s this awesome thing called the Gradle wrapper. In fact, it’s so awesome that the Maven community is going to pick it up soon and put it into their actual core. But it’s been around for several years, and by awesome we mean it’s almost too easy.
You basically tell it what Gradle version you want inside your build file and then everybody who checks out your project will build with a proper version. So why does this matter? Well, anybody who’s had to update somebody’s versions of their tools on their workstations and there’s always the one person who just breaks everything and who can’t get anything right…well, the Gradle wrapper is to help mitigate that. But it also ensures that whenever you check out a piece of code, whenever it was last built, or worked on, it should still build, regardless of what version the tool you have installed because it installs it for you.
2. Gradle is not XML…
Meaning your eyes don’t have to bleed! Maybe you like XML, but I started working with it in 1998. Moving on, in the video we show a little code snippet from Maven as compared to Gradle so you can see the difference for yourself. One of these was designed for a machine, and the other was designed for a human. We’ll let you decide which one you prefer.
3. Gradle plays well with others…
Alright, so maybe it still wants to take over the world but as a tool, right out of the box a version of Ant is embeded into it. Gradle also works with Ivy repositories and Maven repositories, as well as Eclipse and IntelliJ. For Eclipse they actually have an official build-ship plugin by the Gradle folks. Pick a language, C++, Android, Java, and Scala all work with Gradle.
4. Gradle doesn’t waste your time…
Laziness can be a virtue. And when we say lazy, we don’t mean don’t do anything. We mean don’t do anything if you don’t have to do anything. For example, say you’re sitting in a command line and you’re going to go run a build. So it starts compiling, and then it gets to the Checkstyle, then onto FindBugs (perhaps you go get a cup of coffee here), now some tests are running and finally two hours later something has happened. Ok, maybe just two minutes later but it felt like two hours. So perhaps you’re in Ant or Maven, and you may think twice about running that command again.
In Gradle you don’t have to be afraid, you can just run it because it’s going to know what you just changed based on incremental builds and incremental compiles. It uses inputs and outputs, and while some other build systems use things like that as well, but unfortunately they’re time-based ones. So it actually uses a signature of the files to determine if something actually has to be done. This isn’t just in each individual plugin. So Maven has some cool stuff like this, but it’s hit or miss. Some plugins do it and some don’t. This is baked into the tool itself for all tasks to make use of. So it’s inherent and when it works it’s cool. Does it work every single time? No, people can write bad stuff, but if you’re using the tool right, it works.
5. Gradle cares…
Ok, it really doesn’t care, it’s just a tool, but the community does. Here’s what we mean by that. Gradle has not been around anywhere near as long as Ant or Maven and has more than 4x the unique contributors of Maven and more than 10x the unique contributors of Ant. So is this a number that says one community is more awesome than the other, not necessarily, but it is indicative of allowing other people to help make the tool better. So in a much shorter period of time, there are many more people providing inputs and contributions.
What about new releases? If you like something solid, stable, and never changing, Ant’s a pretty good choice. It is really good as a set of utilities, but for an orchestration tool, not so much. How about Maven? Well, Maven isn’t a bad tool for JVM things, but the releases and even the point releases can be a little bit slow. In the video we compare the point releases (minimal releases or short-term releases) per year in Gradle to Ant and Maven. Long-term, like major releases, Maven about every five years you get a brand new Maven. Gradle is about every two years. Is that good or bad? Well that depends on if good stuff is coming in, (people can write bad plugins) but ultimately it does mean that people are actively using it.
Gradle is no longer the new kid on the block. If you’re not using it, or if you haven’t even looked at it, you probably want to consider it.
In Conclusion
If you have any type of question related to Gradle, they have a good set of forums so head straight there https://discuss.gradle.org/. You should also check out the Github source code repository https://github.com/gradle/gradle where you can actually look at the source code and they accept pull requests.
Some books for your consideration:
- Introducing Gradle by Balaji Varanasi
- Gradle in Action by Benjamin Muschko
- Gradle Dependency Management by Hubert Klein Ikkink
- Building and Testing with Gradle by Tim Berglund and Matthew McCullough
- Gradle Effective Implementation Guide by Hubert Klein Ikkink
- Gradle Recipes for Android by Ken Kousen