Extending Gradle: Difference between revisions

From NovaOrdis Knowledge Base
Jump to navigation Jump to search
Line 9: Line 9:
=Extensions Code Location=
=Extensions Code Location=
==In-line in build.gradle==
==In-line in build.gradle==
Both custom tasks ([[Extending_Gradle_with_Custom_Tasks#Simple_Task|simple]] or [[Extending_Gradle_with_Custom_Tasks#Enhanced_Task|enhanced]]) and binary plugins can be fully declared in-line in [[build.gradle]]. While declaring simple custom tasks in-line is acceptable, provided that the tasks are not intended for reuse and sharing among other projects, declaring enhanced tasks or even full binary plugin in-line is, albeit possible, not recommended.
Both custom tasks ([[Extending_Gradle_with_Custom_Tasks#Simple_Task|simple]] or [[Extending_Gradle_with_Custom_Tasks#Enhanced_Task|enhanced]]) and binary plugins can be fully declared in-line in [[build.gradle]]. Placing the extension code here has the benefit that it is automatically compiled and included in the classpath of the build script. While declaring simple custom tasks in-line is acceptable, provided that the task or the plugin are not intended for reuse and sharing among other projects, declaring enhanced tasks or even full binary plugin in-line is, albeit possible, not recommended. The extension code declared in build.gradle is not visible outside the build script and it cannot be reused outside the build script.


Examples:
Examples:

Revision as of 07:59, 24 September 2020

Internal

Overview

The simplest way to extend Gradle is to write a custom task, which can be declared in-line in the project's build.gradle or in a script plugin, in the projects's buildSrc directory or in can be external to project and provided back to the Gradle runtime as a JAR. More complex behavior that goes beyond the capabilities of a custom task can be implemented as a custom object plugin, which has the same choice in terms of where the code lives.

Extensions Code Location

In-line in build.gradle

Both custom tasks (simple or enhanced) and binary plugins can be fully declared in-line in build.gradle. Placing the extension code here has the benefit that it is automatically compiled and included in the classpath of the build script. While declaring simple custom tasks in-line is acceptable, provided that the task or the plugin are not intended for reuse and sharing among other projects, declaring enhanced tasks or even full binary plugin in-line is, albeit possible, not recommended. The extension code declared in build.gradle is not visible outside the build script and it cannot be reused outside the build script.

Examples:

In-line in a script plugin

A script plugin is a regular Gradle build script that can be imported into another build script. Both custom tasks and "binary" plugin code can be declared in-line in a script plugin.

Examples:

In the Project's buildSrc Directory

This is a good choice while developing a custom task or a plugin, because it gives a quick feedback loop and allows for in-line debugging. The 'buildSrc' directory is itself a Gradle project and has a standard Maven layout. It could have a build.gradle, but it seems that for simple Java compilation that does not require external dependencies works without it. buildSrc/build.gradle starts to become useful when the custom code task being developed requires external dependencies. In that case, the dependencies must be declared in buildSrc/build.gradle.

.
├── build.gradle
├── buildSrc
│   ├── build.gradle
│   └── src
│       └── main
│           └── java
│               └── playground
│                   └── gradle
│                       └── CustomEnhancedTask.java
└ ...

Examples:

External Standalone Project

Extension code can live in separate standalone projects that publish JARs. Those JARs can be declared as dependencies by a Gradle project that can then use the custom task or the binary plugin externally developed.

Custom Task

Extending Gradle with Custom Tasks

Custom Binary Plugin

Extending Gradle with Binary Plugins