Extending Gradle: Difference between revisions
No edit summary |
|||
Line 1: | Line 1: | ||
=External= | |||
* https://docs.gradle.org/current/userguide/custom_tasks.html | |||
=Internal= | =Internal= | ||
* [[Gradle Concepts#Extending_Gradle|Gradle Concepts]] | * [[Gradle Concepts#Extending_Gradle|Gradle Concepts]] |
Revision as of 08:04, 24 September 2020
External
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 simple or enhanced tasks 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 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:
- Custom simple task declared in-line in build.gradle
- Custom ehanced Java task declared in-line in build.gradle
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:
- Custom simple task declared in-line in a script plugin.
- Custom enhanced task declared in-line in a script plugin.
In the Project's buildSrc Directory
The source code for the custom task or the plugin can be placed in buildSrc/src/main/java|groovy|kotlin subdirectory of the project directory. Gradle will compile and test the extension code and it will automatically make it available on the classpath of the build script. 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.
The extension code placed here is not visible outside the build and it cannot be reused outside the build it defines it.
.
├── build.gradle
├── buildSrc
│ ├── build.gradle
│ └── src
│ └── main
│ └── java
│ └── playground
│ └── gradle
│ └── CustomEnhancedTask.java
└ ...
Examples:
External Standalone Project
Extension code can live in an external 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.