Extending Gradle: Difference between revisions

From NovaOrdis Knowledge Base
Jump to navigation Jump to search
 
(39 intermediate revisions by the same user not shown)
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]]
* [[Gradle Plugin Concepts]]
* [[Gradle Plugin Concepts]]
* [[Gradle_Task#Defining_Custom_Tasks|Gradle Tasks]]


=Overview=
=Overview=
Line 8: Line 12:


=Extensions Code Location=
=Extensions Code Location=
Gradle does not suggest a specific way of writing extensions, such as tasks and plugins. Tasks can be declared in-line using the DSL keywords, or they can be programming using a JVM-based programming language such as Java or Groovy.
==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]]. 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.
Both custom [[Gradle_Task#Simple_Task|simple]] or [[Gradle_Task#Enhanced_Task|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:
Examples:
Line 16: Line 21:


==In-line in a script plugin==
==In-line in a script plugin==
A [[Gradle_Plugin_Concepts#Script_Plugin|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.
A [[Gradle_Plugin_Concepts#Script_Plugin|script plugin]] is a regular Gradle build script that can be imported into another build script. Both custom [[Gradle_Task#Simple_Task|simple]] or [[Gradle_Task#Enhanced_Task|enhanced]] tasks and [[Extending_Gradle_with_Binary_Plugins#Overview|"binary" plugin code]] can be declared in-line in a script plugin.


Examples:
Examples:
Line 22: Line 27:
* [https://github.com/ovidiuf/playground/tree/master/gradle/extending-gradle/05-script-plugin-enhanced-task Custom enhanced task declared in-line in a script plugin].
* [https://github.com/ovidiuf/playground/tree/master/gradle/extending-gradle/05-script-plugin-enhanced-task Custom enhanced task declared in-line in a script plugin].


==In the Project's buildSrc Directory==
==<span id='In_the_Project.27s_buildSrc_Directory'></span>In the Project's <tt>buildSrc</tt> 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.
The source code for the [[Extending_Gradle_with_a_Custom_Enhanced_Task#Overview|custom enhanced task]] or the [[Extending_Gradle_with_Binary_Plugins#Overview|binary plugin]] can be placed in the '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 works without it for simple Java compilation cases that does not require external dependencies. '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', as shown below in [[#buildSrc_build.gradle_that_Declares_Dependencies|buildSrc build.gradle that Declares Dependencies]] section.
 
The extension code placed here is not visible outside the build and it cannot be reused outside the build it defines it.  
<syntaxhighlight lang='text'>
<syntaxhighlight lang='text'>
.
.
Line 35: Line 42:
│                  └── gradle
│                  └── gradle
│                      └── CustomEnhancedTask.java
│                      └── CustomEnhancedTask.java
...
└── ...
</syntaxhighlight>
 
===<tt>buildSrc</tt> Project Example===
{{External|[https://github.com/ovidiuf/playground/tree/master/gradle/extending-gradle/03-enhanced-task-in-buildSrc Custom enhanced task developed in buildSrc]}}
===<tt>buildSrc</tt> <tt>build.gradle</tt> that Declares Dependencies===
<syntaxhighlight lang='groovy'>
repositories {
  maven {
    url "https://plugins.gradle.org/m2/"
  }
}
dependencies {
  implementation "com.palantir.gradle.docker:gradle-docker:0.25.0"
}
</syntaxhighlight>
</syntaxhighlight>
There are situations when the Gradle extensions developed in buildSrc depend on the libraries that back up plugins used by regular sub-projects during the build. In this case, the dependencies declared in buildSrc build.gradle should be declared on the library, not on plugin. An example is available in [[Configuring_com.palantir.docker_tag_at_Execution_Phase#Identify_the_Plugin_Library|Configuring com.palantir.docker tag at Execution Phase &#124; Identify the Plugin Library]].


Examples:
===Debugging a <tt>buildSrc</tt> Project===
* [https://github.com/ovidiuf/playground/tree/master/gradle/extending-gradle/03-enhanced-task-in-buildSrc Custom enhanced task developed in buildSrc]
{{Internal|Gradle_Operations#Debug_a_Gradle_Build|Gradle Operations &#124; Debug a Gradle Build}}


==<span id='External_to_Project'></span>External Standalone Project==
==<span id='External_to_Project'></span>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.
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.
 
Examples:
* [https://github.com/ovidiuf/playground/tree/master/gradle/extending-gradle/06-enhanced-task-developed-in-standalone-project Custom enhanced task developed in standalone project]. The project publishes the JAR in the local Maven repository.
* [https://github.com/ovidiuf/playground/tree/master/gradle/extending-gradle/07-enhanced-task-imported-from-external-project Custom enhanced task imported from external project]. The project gets the JAR with the task from the local Maven repository.


=Custom Task=
=<span id='Custom_Task'></span>Custom Tasks=
{{Internal|Extending Gradle with Custom Tasks|Extending Gradle with Custom Tasks}}
{{Internal|Gradle_Task#Simple_Task|Extending Gradle with Custom Simple Tasks}}
{{Internal|Extending Gradle with a Custom Enhanced Task#Overview|Extending Gradle with Custom Enhanced Tasks}}


=Custom Binary Plugin=
=Custom Binary Plugin=
{{Internal|Extending Gradle with Binary Plugins|Extending Gradle with Binary Plugins}}
{{Internal|Extending Gradle with Binary Plugins|Extending Gradle with Binary Plugins}}
=Extension=
A [[Gradle_Plugin_Concepts#Plugin_Extension|plugin]] is the typical use case for an extension.

Latest revision as of 02:52, 11 November 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

Gradle does not suggest a specific way of writing extensions, such as tasks and plugins. Tasks can be declared in-line using the DSL keywords, or they can be programming using a JVM-based programming language such as Java or Groovy.

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:

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 simple or enhanced tasks and "binary" plugin code can be declared in-line in a script plugin.

Examples:

In the Project's buildSrc Directory

The source code for the custom enhanced task or the binary plugin can be placed in the '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 works without it for simple Java compilation cases that does not require external dependencies. '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', as shown below in buildSrc build.gradle that Declares Dependencies section.

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
└── ...

buildSrc Project Example

Custom enhanced task developed in buildSrc

buildSrc build.gradle that Declares Dependencies

repositories {
  maven {
    url "https://plugins.gradle.org/m2/"
  }
}
dependencies {
  implementation "com.palantir.gradle.docker:gradle-docker:0.25.0"
}

There are situations when the Gradle extensions developed in buildSrc depend on the libraries that back up plugins used by regular sub-projects during the build. In this case, the dependencies declared in buildSrc build.gradle should be declared on the library, not on plugin. An example is available in Configuring com.palantir.docker tag at Execution Phase | Identify the Plugin Library.

Debugging a buildSrc Project

Gradle Operations | Debug a Gradle Build

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.

Examples:

Custom Tasks

Extending Gradle with Custom Simple Tasks
Extending Gradle with Custom Enhanced Tasks

Custom Binary Plugin

Extending Gradle with Binary Plugins

Extension

A plugin is the typical use case for an extension.