The following is the first few sections of a chapter from The Busy Coder's Guide to Android Development, plus headings for the remaining major sections, to give you an idea about the content of the chapter.
Gradle is very extensible, from Groovy scripting code in your
file all the way up to dedicated Gradle plugins. The more you want
to reuse a particular piece of functionality, or the more sophistication
you want in your custom builds, the more likely it is that a Gradle plugin
will be the right solution.
Sometimes, a Gradle plugin will be focused mostly on tailoring the build process itself. However, a Gradle plugin could be simply an integration point for a tool that could be used in other ways (e.g., command-line API) that would not otherwise require Gradle. This is particularly true for tools that work across IDEs, where you put most of the core logic into a core set of tool code and have thin build system plugins that bridge between the build system or IDE and the tool itself.
In this chapter, we will look at the basics of setting up a Gradle plugin. The plugin that we develop in this chapter will not do much of anything. The next chapter, however, creates a Gradle plugin that generates Java code, building on what we explore here.
This chapter will make the most sense if you have read the preceding chapters on Gradle, particularly the chapter on Gradle tasks and the chapter on Gradle dependencies.
Gradle is Groovy — in other words, Gradle is a domain specific language
(DSL) implemented in the Groovy scripting language. Hence, you are welcome
to blend in Groovy code into your
build.gradle file, for everything
from simple string concatenation to loops, branches, and everything else
that you would expect from a modern OO-flavored scripting language.
You are not limited to putting that Groovy code directly in
either. You can use
apply from: to indicate the path to some other
Gradle script, reminiscent of a
#include from C/C++,
in an Android layout resource, and so forth:
apply from: 'relative/path/to/some.gradle'
Or, you can create a
buildSrc/ directory in your project root. In
there, you can have Java code (e.g., in
src/main/java/) or Groovy code
src/main/groovy/), all of which will be compiled and added
to the classpath for your main
build.gradle file. As a result, your
build.gradle file can refer to whatever classes and such are created
buildSrc/ quasi-module. This is powerful, but it is inconvenient
to distribute, except for other people working on the same overall project
(e.g., via version control systems). As such, this approach is mostly
for project-specific build system extensions.
A Gradle plugin is a separate module, akin to the
that creates a JAR that incorporates compiled Java and Groovy code.
That plugin JAR can then be used by other modules or other projects. The
plugin can be distributed through Maven Central, JCenter, or other
artifact repositories. And, people can use it just like you use the
Android Plugin for Gradle: requesting it in a
and applying the plugin. This is somewhat more complicated to set up
than is a
buildSrc/ directory, but it offers the easiest path for
distributing substantial build customizations.
The preview of this section is presently indisposed.
The preview of this section took that left turn at Albuquerque.
The preview of this section will not appear here for a while, due to a time machine mishap.
The preview of this section is unavailable right now, but if you leave your name and number at the sound of the tone, it might get back to you (BEEEEEEEEEEEEP!).
The preview of this section was whisked away by a shark-infested tornado.