Most builds start out simple and end up complex. Gradle is designed to handle this complexity naturally through its easy-to-use plugin API. More than just a way to script together a few custom scripts, Gradle plugins have the ability to alter the domain model of the build tool itself, letting you express your complex build requirements in simple and elegant extensions to Gradle's DSL. In the course, you'll see Tim create a plugin to help build Asciidoctor presentations, starting from boilerplate build and ending up with a fully customized, published plugin consumed from the plugin portal. The course materials are available at: https://github.com/tlberglund/asciidoctor-presentation.
Teacher, author, frequent speaker, technology leader. Leads the curriculum team at DataStax.
Section Introduction Transcripts
Section Introduction Transcripts
Which Plugin Architecture? I'm Tim Berglund. I've been a developer for a long time, I've been a Gradle user for about the past five years, I've written a couple of books on Gradle, taught classes on it. And what we're going to do today is look at how to write a custom plugin. Now, there's a lot of subtlety to this. On the one hand, I'm just going to be showing you Gradle APIs. We're going to pick an example domain, a reason that we need to extend Gradle, and we'll write some code using the Gradle APIs. As we do that, we're going to learn a little bit about Gradle's philosophy and its approach to builds. There is a subtler point here about extending Gradle: The way you should think about your build process and think about customizing your build as a first-class software development activity. Let me give you a preview of the topics we're going to cover. We'll begin by reviewing the nature of builds, historically what different build tools in the JVM ecosystem have really though about builds and where Gradle fits into that world. We'll look at the various plugin architectures those build tools have supported and, again, see where Gradle's plugin architecture fits in that continuum. We'll look at some of the Gradle plugins that already exist and, trust me, this is a rich ecosystem. If you're already a Gradle user, you probably know this. If you've ever built a Java program with Gradle, which is what most people do first, you've already used a Gradle plugin. There are Gradle plugins that come packaged with Gradle, there are Gradle plugins that are provided by the open source community and it's worth exploring those. We'll spend just a little bit of time doing that. Once we start to think about some actual customizations doing the things that Gradle doesn't do by default that we want our build to do, we're going to see what happens. We're going to see imperative logic creep into our build. It's really easy to get started that way. A Gradle build script, as you may know, is just groovy code and you can do all kinds of things in there. Very flexible, very quick to get started. But you'll see this becomes a problem before long and it gets messy and we want to be careful with the way we manage imperative logic. A big part of that management is going to be the concept of domain modeling. A Gradle build is, as I said, a first-class piece of code. It's software unlike any other software that you might write. And the build itself is a domain that we have to model in that code. We'll see we're going to introduce other kinds of objects that aren't already a part of Gradle's model into our build and we're going to model them in an easy to understand way. After all of that, we will finally get a look at the actual Gradle plugin API. The code we're going to end up with isn't all that bad, but a lot of the steps we have to take are not at all obvious, so you're going to be grateful for the process of walking through, building that code a piece at a time, and having an example to look at when you're all done. Finally, we'll look at how to package and distribute our plugin. In the early stages of plugin development, you just want everything to be local. You want to see your changes, you want to be able to iterate very quickly as you're exploring the domain and figuring out how all the APIs work. In the end, this is the thing we're going to want to publish to the Gradle plugin portal so that it's very easy for other people to access it and get new releases as we push those live. So as you can see there's a lot of material to cover. Let's get started.