/usr/share/doc/gradle/userguide/plugins.html

<html><head><META http-equiv="Content-Type" content="text/html; charset=UTF-8"><title>Gradle Plugins - Gradle User Guide Version 3.4.1</title><link xmlns:xslthl="http://xslthl.sf.net" type="text/css" rel="stylesheet" href="base.css"><link xmlns:xslthl="http://xslthl.sf.net" type="text/css" rel="stylesheet" href="docs.css"><link xmlns:xslthl="http://xslthl.sf.net" type="text/css" rel="stylesheet" href="userguide.css"><meta content="DocBook XSL Stylesheets V1.79.1" name="generator"><link rel="home" href="userguide.html" title="Gradle User Guide Version 3.4.1"><link rel="up" href="pt03.html" title="Part&nbsp;III.&nbsp;Writing Gradle build scripts"><link rel="prev" href="multi_project_builds.html" title="Multi-project Builds - Gradle User Guide Version 3.4.1"><link rel="next" href="standard_plugins.html" title="Standard Gradle plugins - Gradle User Guide Version 3.4.1"></head><body><div class="navheader"><div><div class="navbar"><a xmlns:xslthl="http://xslthl.sf.net" href="multi_project_builds.html" title="Multi-project Builds - Gradle User Guide Version 3.4.1">Previous</a><span>|</span><a xmlns:xslthl="http://xslthl.sf.net" href="userguide.html" title="Gradle User Guide Version 3.4.1">Contents</a><span>|</span><a xmlns:xslthl="http://xslthl.sf.net" href="standard_plugins.html" title="Standard Gradle plugins - Gradle User Guide Version 3.4.1">Next</a></div></div></div><div class="chapter"><div class="titlepage"><div><div><h1 xmlns:xslthl="http://xslthl.sf.net"><a name="plugins"></a>Chapter&nbsp;27.&nbsp;Gradle Plugins</h1></div></div></div><div class="toc"><p><b>Table of Contents</b></p><dl class="toc"><dt><span class="section"><a href="plugins.html#sec:what_plugins_do">27.1. What plugins do</a></span></dt><dt><span class="section"><a href="plugins.html#sec:types_of_plugins">27.2. Types of plugins</a></span></dt><dt><span class="section"><a href="plugins.html#sec:using_plugins">27.3. Using plugins</a></span></dt><dt><span class="section"><a href="plugins.html#sec:script_plugins">27.4. Script plugins</a></span></dt><dt><span class="section"><a href="plugins.html#sec:binary_plugins">27.5. Binary plugins</a></span></dt><dt><span class="section"><a href="plugins.html#sec:finding_community_plugins">27.6. Finding community plugins</a></span></dt><dt><span class="section"><a href="plugins.html#sec:more_on_plugins">27.7. More on plugins</a></span></dt></dl></div><p>
        Gradle at its core intentionally provides very little for real world automation. All of the useful
        features, like the ability to compile Java code, are added by <span class="emphasis"><em>plugins</em></span>.
        Plugins add new tasks (e.g. <a class="ulink" href="../dsl/org.gradle.api.tasks.compile.JavaCompile.html" target="_top"><code class="classname">JavaCompile</code></a>), domain objects (e.g.
        <a class="ulink" href="../dsl/org.gradle.api.tasks.SourceSet.html" target="_top"><code class="classname">SourceSet</code></a>), conventions (e.g. Java source is located at
        <code class="literal">src/main/java</code>) as well as extending core objects and objects from other plugins.
    </p><p>
        In this chapter we discuss how to use plugins and the terminology and concepts surrounding plugins.
    </p><div class="section"><div class="titlepage"><div><div><h2 class="title"><a xmlns:xslthl="http://xslthl.sf.net" name="sec:what_plugins_do" class="section-anchor" href="#sec:what_plugins_do"></a>27.1.&nbsp;What plugins do</h2></div></div></div><p>
            Applying a plugin to a project allows the plugin to extend the project's capabilities. It can do things
            such as:
        </p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem">Extend the Gradle model (e.g. add new DSL elements that can be configured)</li><li class="listitem">Configure the project according to conventions (e.g. add new tasks or configure sensible defaults)</li><li class="listitem">Apply specific configuration (e.g. add organizational repositories or enforce standards)</li></ul></div><p>
            By applying plugins, rather than adding logic to the project build script, we can reap a number of benefits.  Applying plugins:
        </p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem">Promotes reuse and reduces the overhead of maintaining similar logic across multiple projects</li><li class="listitem">Allows a higher degree of modularization, enhancing comprehensibility and organization</li><li class="listitem">Encapsulates imperative logic and allows build scripts to be as declarative as possible</li></ul></div></div><div class="section"><div class="titlepage"><div><div><h2 class="title"><a xmlns:xslthl="http://xslthl.sf.net" name="sec:types_of_plugins" class="section-anchor" href="#sec:types_of_plugins"></a>27.2.&nbsp;Types of plugins</h2></div></div></div><p>
            There are two general types of plugins in Gradle, <span class="emphasis"><em>script</em></span> plugins and <span class="emphasis"><em>binary</em></span> plugins.
            Script plugins are additional build scripts that further configure the build and usually implement a declarative approach to
            manipulating the build. They are typically used within a build although they can be externalized and accessed from a remote
            location. Binary plugins are classes that implement the <a class="ulink" href="../javadoc/org/gradle/api/Plugin.html" target="_top"><code class="classname">Plugin</code></a> interface and adopt a programmatic
            approach to manipulating the build. Binary plugins can reside within a build script, within the project hierarchy or externally
            in a plugin jar.
        </p><p>
            A plugin often starts out as a script plugin (because they are easy to write) and then, as the code becomes more valuable, it's
            migrated to a binary plugin that can be easily tested and shared between multiple projects or organizations.
        </p></div><div class="section"><div class="titlepage"><div><div><h2 class="title"><a xmlns:xslthl="http://xslthl.sf.net" name="sec:using_plugins" class="section-anchor" href="#sec:using_plugins"></a>27.3.&nbsp;Using plugins</h2></div></div></div><p>
            To use the build logic encapsulated in a plugin, Gradle needs to perform two steps. First, it needs to <span class="emphasis"><em>resolve</em></span> the
            plugin, and then it needs to <span class="emphasis"><em>apply</em></span> the plugin to the target, usually a <a class="ulink" href="../dsl/org.gradle.api.Project.html" target="_top"><code class="classname">Project</code></a>.
        </p><p>
            <span class="emphasis"><em>Resolving</em></span> a plugin means finding the correct version of the jar which contains a given plugin and adding it the
            script classpath. Once a plugin is resolved, its API can be used in a build script. Script plugins are self-resolving in that they are
            resolved from the specific file path or URL provided when applying them. Core binary plugins provided as part of the Gradle distribution
            are automatically resolved.
        </p><p>
            <span class="emphasis"><em>Applying</em></span> a plugin means actually executing the plugin's <a class="ulink" href="../javadoc/org/gradle/api/Plugin.html#apply(T)" target="_top"><code class="classname">Plugin.apply(T)</code></a>
            on the Project you want to enhance with the plugin. Applying plugins is <span class="emphasis"><em>idempotent</em></span>. That is, you can safely apply
            any plugin multiple times without side effects.
        </p><p>
            The most common use case for using a plugin is to both resolve the plugin and apply it to the current project. Since this is such a
            common use case, it's recommended that build authors use the <a class="link" href="plugins.html#sec:plugins_block">plugins DSL</a> to both resolve and
            apply plugins in one step. The feature is technically still incubating, but it works well, and should be used by most users.
        </p></div><div class="section"><div class="titlepage"><div><div><h2 class="title"><a xmlns:xslthl="http://xslthl.sf.net" name="sec:script_plugins" class="section-anchor" href="#sec:script_plugins"></a>27.4.&nbsp;Script plugins</h2></div></div></div><div class="example"><a xmlns:xslthl="http://xslthl.sf.net" name="configureProjectUsingScript"></a><p class="title"><b>Example&nbsp;27.1.&nbsp;Applying a script plugin</b></p><div class="example-contents"><p><code class="filename">build.gradle</code></p><pre class="programlisting">apply from: <span xmlns:xslthl="http://xslthl.sf.net" class="hl-string">'other.gradle'</span>
</pre></div></div><br class="example-break"><p>
            Script plugins are automatically resolved and can be applied from a script on the local filesystem or at a remote location.
            Filesystem locations are relative to the project directory, while remote script locations are specified with an HTTP URL.
            Multiple script plugins (of either form) can be applied to a given target.
        </p></div><div class="section"><div class="titlepage"><div><div><h2 class="title"><a xmlns:xslthl="http://xslthl.sf.net" name="sec:binary_plugins" class="section-anchor" href="#sec:binary_plugins"></a>27.5.&nbsp;Binary plugins</h2></div></div></div><p>
            You apply plugins by their <span class="emphasis"><em>plugin id</em></span>, which is a globally unique identifier, or name, for plugins.
            Core Gradle plugins are special in that they provide short names, such as <code class="literal">'java'</code> for the core
            <a class="ulink" href="../javadoc/org/gradle/api/plugins/JavaPlugin.html" target="_top"><code class="classname">JavaPlugin</code></a>. All other binary plugins must use the fully qualified form of
            the plugin id (e.g. <code class="literal">com.github.foo.bar</code>), although some legacy plugins may still utilize a short, unqualified
            form. Where you put the plugin id depends on whether you are using the <a class="link" href="plugins.html#sec:plugins_block">plugins DSL</a> or
            the <a class="link" href="plugins.html#sec:old_plugin_application">buildscript block.</a>
        </p><div class="section"><div class="titlepage"><div><div><h3 class="title"><a xmlns:xslthl="http://xslthl.sf.net" name="sec:binary_plugin_locations" class="section-anchor" href="#sec:binary_plugin_locations"></a>27.5.1.&nbsp;Locations of binary plugins</h3></div></div></div><p>
                A plugin is simply any class that implements the <a class="ulink" href="../javadoc/org/gradle/api/Plugin.html" target="_top"><code class="classname">Plugin</code></a> interface. Gradle provides
                the core plugins (e.g. <code class="literal">JavaPlugin</code>) as part of its distribution which means they are automatically resolved.
                However, non-core binary plugins need to be resolved before they can be applied. This can be achieved in a number of ways:
            </p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem">Including the plugin from the plugin portal or a
                    <a class="link" href="plugins.html#sec:custom_plugin_repositories">custom repository</a> using the plugins DSL
                    (see <a class="xref" href="plugins.html#sec:plugins_block">Section&nbsp;27.5.2, &ldquo;Applying plugins with the plugins DSL&rdquo;</a>).</li><li class="listitem">Including the plugin from an external jar defined as a buildscript dependency
                    (see <a class="xref" href="plugins.html#sec:applying_plugins_buildscript">the section called &ldquo;Applying plugins with the buildscript block&rdquo;</a>).</li><li class="listitem">Defining the plugin as a source file under the buildSrc directory in the project
                    (see <a class="xref" href="organizing_build_logic.html#sec:build_sources">Section&nbsp;43.4, &ldquo;Build sources in the <code class="filename">buildSrc</code> project&rdquo;</a>).</li><li class="listitem">Defining the plugin as an inline class declaration inside a build script.</li></ul></div><p>
                For more on defining your own plugins, see <a class="xref" href="custom_plugins.html">Chapter&nbsp;41, <i>Writing Custom Plugins</i></a>.
            </p></div><div class="section"><div class="titlepage"><div><div><h3 class="title"><a xmlns:xslthl="http://xslthl.sf.net" name="sec:plugins_block" class="section-anchor" href="#sec:plugins_block"></a>27.5.2.&nbsp;Applying plugins with the plugins DSL</h3></div></div></div><div class="note"><p>
                    The plugins DSL is currently <a class="link" href="feature_lifecycle.html">incubating</a>.
                    Please be aware that the DSL and other configuration may change in later Gradle versions.
                </p></div><p>
                The new plugins DSL provides a succinct and convenient way to declare plugin dependencies. It works with the
                <a class="ulink" href="http://plugins.gradle.org" target="_top">Gradle plugin portal</a> to provide easy access to both core and community
                plugins. The plugins DSL block configures an instance of <a class="ulink" href="../dsl/org.gradle.plugin.use.PluginDependenciesSpec.html" target="_top"><code class="classname">PluginDependenciesSpec</code></a>.
            </p><p>
                To apply a core plugin, the short name can be used:
            </p><div class="example"><a xmlns:xslthl="http://xslthl.sf.net" name="useJavaPluginDSL"></a><p class="title"><b>Example&nbsp;27.2.&nbsp;Applying a core plugin</b></p><div class="example-contents"><p><code class="filename">build.gradle</code></p><pre class="programlisting">plugins {
    id <span xmlns:xslthl="http://xslthl.sf.net" class="hl-string">'java'</span>
}
</pre></div></div><br class="example-break"><p>
                To apply a community plugin from the portal, the fully qualified plugin id must be used:
            </p><div class="example"><a xmlns:xslthl="http://xslthl.sf.net" name="useCommunityPluginDSL"></a><p class="title"><b>Example&nbsp;27.3.&nbsp;Applying a community plugin</b></p><div class="example-contents"><p><code class="filename">build.gradle</code></p><pre class="programlisting">plugins {
    id <span xmlns:xslthl="http://xslthl.sf.net" class="hl-string">"com.jfrog.bintray"</span> version <span xmlns:xslthl="http://xslthl.sf.net" class="hl-string">"0.4.1"</span>
}
</pre></div></div><br class="example-break"><p>
                See <a class="ulink" href="../dsl/org.gradle.plugin.use.PluginDependenciesSpec.html" target="_top"><code class="classname">PluginDependenciesSpec</code></a> for more information on using the Plugin DSL.
            </p><div class="section"><div class="titlepage"><div><div><h4 class="title"><a xmlns:xslthl="http://xslthl.sf.net" name="plugins_dsl_limitations" class="section-anchor" href="#plugins_dsl_limitations"></a>Limitations of the plugins DSL</h4></div></div></div><p>
                    This way of adding plugins to a project is much more than a more convenient syntax. The plugins DSL is processed in a way which
                    allows Gradle to determine the plugins in use very early and very quickly. This allows Gradle to do smart things such as:
                </p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem">Optimize the loading and reuse of plugin classes.</li><li class="listitem">Allow different plugins to use different versions of dependencies.</li><li class="listitem">Provide editors detailed information about the potential properties and values in the buildscript for
                        editing assistance.</li></ul></div><p>
                    This requires that plugins be specified in a way that Gradle can easily and quickly extract, before executing the
                    rest of the build script. It also requires that the definition of plugins to use be somewhat static.
                </p><p>
                    There are some key differences between the new plugin mechanism and the &ldquo;traditional&rdquo; <code class="code">apply()</code> method
                    mechanism. There are also some constraints, some of which are temporary limitations while the mechanism is still
                    being developed and some are inherent to the new approach.
                </p><div class="section"><div class="titlepage"><div><div><h5 class="title"><a xmlns:xslthl="http://xslthl.sf.net" name="sec:constrained_syntax" class="section-anchor" href="#sec:constrained_syntax"></a>Constrained Syntax</h5></div></div></div><p>
                        The new <code class="code">plugins {}</code> block does not support arbitrary Groovy code. It is constrained, in order to be idempotent
                        (produce the same result every time) and side effect free (safe for Gradle to execute at any time).
                    </p><p>
                        The form is:
                    </p><pre class="programlisting">
plugins {
    id &laquo;plugin id&raquo; version &laquo;plugin version&raquo; [apply &laquo;false&raquo;]
}
</pre><p>
                        Where <code class="literal">&laquo;plugin version&raquo;</code> and <code class="literal">&laquo;plugin id&raquo;</code> must be constant, literal, strings and
                        the <code class="literal">apply</code> statement with a <code class="literal">boolean</code> can be used to disable the default behavior
                        of applying the plugin immediately (e.g. you want to apply it only in <code class="literal">subprojects</code>). No other statements
                        are allowed; their presence will cause a compilation error.
                    </p><p>
                        The <code class="code">plugins {}</code> block must also be a top level statement in the buildscript. It cannot be nested inside
                        another construct (e.g. an if-statement or for-loop).
                    </p></div><div class="section"><div class="titlepage"><div><div><h5 class="title"><a xmlns:xslthl="http://xslthl.sf.net" name="sec:build_scripts_only" class="section-anchor" href="#sec:build_scripts_only"></a>Can only be used in build scripts</h5></div></div></div><p>
                        The <code class="code">plugins {}</code> block can currently only be used in a project's build script. It cannot be used in
                        script plugins, the settings.gradle file or init scripts.
                    </p><p>
                        <span class="emphasis"><em>Future versions of Gradle will remove this restriction.</em></span>
                    </p></div><p>
                    If the restrictions of the new syntax are prohibitive, the recommended approach is to apply plugins using the
                    <a class="link" href="plugins.html#sec:applying_plugins_buildscript">buildscript {} block</a>.
                </p></div><div class="section"><div class="titlepage"><div><div><h4 class="title"><a xmlns:xslthl="http://xslthl.sf.net" name="sec:subprojects_plugins_dsl" class="section-anchor" href="#sec:subprojects_plugins_dsl"></a>Applying plugins to subprojects</h4></div></div></div><p>
                    If you have a <a class="link" href="multi_project_builds.html">multi-project build</a>, you probably want to apply plugins to some or
                    all of the subprojects in your build, but not to the <code class="literal">root</code> or <code class="literal">master</code> project. The default
                    behavior of the <code class="literal">plugins {}</code> block is to immediately <code class="literal">resolve</code> <span class="emphasis"><em>and
                    <code class="literal">apply</code></em></span> the plugins. But, you can use the <code class="literal">apply false</code> syntax to tell Gradle not
                    to apply the plugin to the current project and then use <code class="literal">apply plugin: &laquo;plugin version&raquo;</code> in the
                    <code class="literal">subprojects</code> block:
                </p><div class="example"><a xmlns:xslthl="http://xslthl.sf.net" name="pluginsOnSubprojects"></a><p class="title"><b>Example&nbsp;27.4.&nbsp;Applying plugins only on certain subprojects.</b></p><div class="example-contents"><p><code class="filename">settings.gradle</code></p><pre class="programlisting">include <span xmlns:xslthl="http://xslthl.sf.net" class="hl-string">'helloA'</span>
include <span xmlns:xslthl="http://xslthl.sf.net" class="hl-string">'helloB'</span>
include <span xmlns:xslthl="http://xslthl.sf.net" class="hl-string">'goodbyeC'</span>
</pre><p><code class="filename">build.gradle</code></p><pre class="programlisting">plugins {
  id <span xmlns:xslthl="http://xslthl.sf.net" class="hl-string">"org.gradle.sample.hello"</span> version <span xmlns:xslthl="http://xslthl.sf.net" class="hl-string">"1.0.0"</span> apply false
  id <span xmlns:xslthl="http://xslthl.sf.net" class="hl-string">"org.gradle.sample.goodbye"</span> version <span xmlns:xslthl="http://xslthl.sf.net" class="hl-string">"1.0.0"</span> apply false
}

subprojects { subproject -&gt;
    <span xmlns:xslthl="http://xslthl.sf.net" class="hl-keyword">if</span> (subproject.name.startsWith(<span xmlns:xslthl="http://xslthl.sf.net" class="hl-string">"hello"</span>)) {
        apply plugin: <span xmlns:xslthl="http://xslthl.sf.net" class="hl-string">'org.gradle.sample.hello'</span>
    }
    <span xmlns:xslthl="http://xslthl.sf.net" class="hl-keyword">if</span> (subproject.name.startsWith(<span xmlns:xslthl="http://xslthl.sf.net" class="hl-string">"goodbye"</span>)) {
        apply plugin: <span xmlns:xslthl="http://xslthl.sf.net" class="hl-string">'org.gradle.sample.goodbye'</span>
    }
}
</pre></div></div><br class="example-break"><p>
                    If you then run <code class="literal">gradle hello</code> you'll see that only the helloA and helloB subprojects had the hello plugin
                    applied.
                </p><pre class="programlisting">
gradle/subprojects/docs/src/samples/plugins/multiproject $&gt; gradle hello
Parallel execution is an incubating feature.
:helloA:hello
:helloB:hello
Hello!
Hello!

BUILD SUCCESSFUL
</pre></div><div class="section"><div class="titlepage"><div><div><h4 class="title"><a xmlns:xslthl="http://xslthl.sf.net" name="sec:custom_plugin_repositories" class="section-anchor" href="#sec:custom_plugin_repositories"></a>Custom Plugin Repositories</h4></div></div></div><div class="note"><p>
                        The <code class="code">pluginRepositories {}</code> DSL is currently <a class="link" href="feature_lifecycle.html">incubating</a>.
                        Please be aware that the DSL and other configuration may change in later Gradle versions.
                    </p></div><p>
                    By default, the <code class="code">plugins {}</code> DSL resolves plugins from the public <a class="ulink" href="https://plugins.gradle.org" target="_top">Gradle Plugin Portal.</a>
                    Many build authors would also like to resolve plugins from private Maven or Ivy repositories because the plugins contain proprietary implementation
                    details, or just to have more control over what plugins are available to their builds.
                </p><p>
                    To specify custom plugin repositories, add a <code class="code">pluginRepositories {}</code> block to the <code class="code">settings.gradle</code> file:
                </p><div class="example"><a xmlns:xslthl="http://xslthl.sf.net" name="customPluginRepositories"></a><p class="title"><b>Example&nbsp;27.5.&nbsp;Using plugins from custom plugin repositories.</b></p><div class="example-contents"><p><code class="filename">settings.gradle</code></p><pre class="programlisting">pluginRepositories {
  maven {
    url <span xmlns:xslthl="http://xslthl.sf.net" class="hl-string">'maven-repo'</span>
  }
  gradlePluginPortal()
  ivy {
    url <span xmlns:xslthl="http://xslthl.sf.net" class="hl-string">'ivy-repo'</span>
  }
}
</pre></div></div><br class="example-break"><p>
                    This tells Gradle to first look in the Maven repository at <code class="literal">maven-repo</code> when resolving plugins and then to
                    check the Gradle Plugin Portal if the plugins are not found in the Maven repository. If you don't want the Gradle Plugin Portal to be searched,
                    omit the <code class="code">gradlePluginPortal()</code> line. Finally, the Ivy repository at <code class="literal">ivy-repo</code> will be checked.
                </p><p>
                    The <code class="code">pluginRepositories {}</code> block may only appear in the <code class="code">settings.gradle</code> file, and must be the first block in the file.
                    Custom Maven and Ivy plugin repositories must contain <a class="link" href="plugins.html#sec:plugin_markers">plugin marker artifacts</a> in addition to the artifacts
                    which actually implement the plugin. For more information on publishing plugins to custom repositories read <a class="xref" href="javaGradle_plugin.html">Chapter&nbsp;42, <i>The Java Gradle Plugin Development Plugin</i></a>.
                </p><p>
                    See <a class="ulink" href="../dsl/org.gradle.plugin.repository.PluginRepositoriesSpec.html" target="_top"><code class="classname">PluginRepositoriesSpec</code></a> for complete documentation for using the
                    <code class="code">pluginRepositories {}</code> block.
                </p></div><div class="section"><div class="titlepage"><div><div><h4 class="title"><a xmlns:xslthl="http://xslthl.sf.net" name="sec:plugin_markers" class="section-anchor" href="#sec:plugin_markers"></a>Plugin Marker Artifacts</h4></div></div></div><p>
                    Since the <code class="code">plugins {}</code> DSL block only allows for declaring plugins by their globally unique plugin <code class="literal">id</code> and
                    <code class="literal">version</code> properties, Gradle needs a way to look up the coordinates of the plugin implementation artifact. To do so,
                    Gradle will look for a Plugin Marker Artifact with the coordinates <code class="literal">plugin.id:plugin.id.gradle.plugin:plugin.version</code>.
                    This marker needs to have a dependency on the actual plugin implementation. Publishing these markers is automated by the
                    <a class="link" href="javaGradle_plugin.html">java-gradle-plugin</a>.
                </p><p>
                    For example, the following complete sample from the <code class="literal">sample-plugins</code> project shows how to publish a
                    <code class="literal">org.gradle.sample.hello</code> plugin and a <code class="literal">org.gradle.sample.goodbye</code> plugin to both an Ivy and Maven repository
                    using the combination of the <a class="link" href="javaGradle_plugin.html">java-gradle-plugin</a>, the
                    <a class="link" href="publishing_maven.html">maven-publish</a> plugin, and the <a class="link" href="publishing_ivy.html">ivy-publish</a> plugin.
                </p><div class="example"><a xmlns:xslthl="http://xslthl.sf.net" name="completePluginPublishing"></a><p class="title"><b>Example&nbsp;27.6.&nbsp;Complete Plugin Publishing Sample</b></p><div class="example-contents"><p><code class="filename">build.gradle</code></p><pre class="programlisting">plugins {
  id <span xmlns:xslthl="http://xslthl.sf.net" class="hl-string">'java-gradle-plugin'</span>
  id <span xmlns:xslthl="http://xslthl.sf.net" class="hl-string">'maven-publish'</span>
  id <span xmlns:xslthl="http://xslthl.sf.net" class="hl-string">'ivy-publish'</span>
}

group <span xmlns:xslthl="http://xslthl.sf.net" class="hl-string">'org.gradle.sample'</span>
version <span xmlns:xslthl="http://xslthl.sf.net" class="hl-string">'1.0.0'</span>

gradlePlugin {
  plugins {
    hello {
      id = <span xmlns:xslthl="http://xslthl.sf.net" class="hl-string">"org.gradle.sample.hello"</span>
      implementationClass = <span xmlns:xslthl="http://xslthl.sf.net" class="hl-string">"org.gradle.sample.hello.HelloPlugin"</span>
    }
    goodbye {
      id = <span xmlns:xslthl="http://xslthl.sf.net" class="hl-string">"org.gradle.sample.goodbye"</span>
      implementationClass = <span xmlns:xslthl="http://xslthl.sf.net" class="hl-string">"org.gradle.sample.goodbye.GoodbyePlugin"</span>
    }
  }
}

publishing {
  repositories {
    maven {
      url <span xmlns:xslthl="http://xslthl.sf.net" class="hl-string">"../consuming/maven-repo"</span>
    }
    ivy {
      url <span xmlns:xslthl="http://xslthl.sf.net" class="hl-string">"../consuming/ivy-repo"</span>
    }
  }
}
</pre></div></div><br class="example-break"><p>
                    Running <code class="literal">gradle publish</code> in the sample directory causes the following repo layouts to exist:
                </p><p>
                    <img src="img/pluginMarkers.png">
                </p></div></div><div class="section"><div class="titlepage"><div><div><h3 class="title"><a xmlns:xslthl="http://xslthl.sf.net" name="sec:old_plugin_application" class="section-anchor" href="#sec:old_plugin_application"></a>27.5.3.&nbsp;Legacy Plugin Application</h3></div></div></div><p>
                With the introduction of the <a class="link" href="plugins.html#sec:plugins_block">plugins DSL</a>, users should have little reason
                to use the legacy method of applying plugins. It is documented here in case a build author cannot use the plugins
                DSL due to restrictions in how it currently works.
            </p><div class="section"><div class="titlepage"><div><div><h4 class="title"><a xmlns:xslthl="http://xslthl.sf.net" name="sec:applying_binary_plugins" class="section-anchor" href="#sec:applying_binary_plugins"></a>Applying Binary Plugins</h4></div></div></div><div class="example"><a xmlns:xslthl="http://xslthl.sf.net" name="useJavaPlugin"></a><p class="title"><b>Example&nbsp;27.7.&nbsp;Applying a binary plugin</b></p><div class="example-contents"><p><code class="filename">build.gradle</code></p><pre class="programlisting">apply plugin: <span xmlns:xslthl="http://xslthl.sf.net" class="hl-string">'java'</span>
</pre></div></div><br class="example-break"><p>
                    Plugins can be applied using a <span class="emphasis"><em>plugin id</em></span>. In the above case, we are
                    using the short name &lsquo;<code class="literal">java</code>&rsquo; to apply the <a class="ulink" href="../javadoc/org/gradle/api/plugins/JavaPlugin.html" target="_top"><code class="classname">JavaPlugin</code></a>.
                </p><p>
                    Rather than using a plugin id, plugins can also be applied by simply specifying the class of the plugin:
                </p><div class="example"><a xmlns:xslthl="http://xslthl.sf.net" name="pluginIntro"></a><p class="title"><b>Example&nbsp;27.8.&nbsp;Applying a binary plugin by type</b></p><div class="example-contents"><p><code class="filename">build.gradle</code></p><pre class="programlisting">apply plugin: JavaPlugin
</pre></div></div><br class="example-break"><p>
                    The <code class="literal">JavaPlugin</code> symbol in the above sample refers to the the <a class="ulink" href="../javadoc/org/gradle/api/plugins/JavaPlugin.html" target="_top"><code class="classname">JavaPlugin</code></a>.
                    This class does not strictly need to be imported as the <code class="literal">org.gradle.api.plugins</code> package is automatically imported in all build scripts
                    (see <a class="xref" href="writing_build_scripts.html#script-default-imports">Section&nbsp;18.8, &ldquo;Default imports&rdquo;</a>). Furthermore, it is not necessary to append <code class="literal">.class</code> to identify a class literal in Groovy as it is in Java.
                </p></div><div class="section"><div class="titlepage"><div><div><h4 class="title"><a xmlns:xslthl="http://xslthl.sf.net" name="sec:applying_plugins_buildscript" class="section-anchor" href="#sec:applying_plugins_buildscript"></a>Applying plugins with the buildscript block</h4></div></div></div><p>
                    Binary plugins that have been published as external jar files can be added to a project by adding the plugin to the
                    build script classpath and then applying the plugin.  External jars can be added to the build script classpath
                    using the <code class="code">buildscript {}</code> block as described in <a class="xref" href="organizing_build_logic.html#sec:build_script_external_dependencies">Section&nbsp;43.6, &ldquo;External dependencies for the build script&rdquo;</a>.
                </p><div class="example"><a xmlns:xslthl="http://xslthl.sf.net" name="applyPluginBuildscript"></a><p class="title"><b>Example&nbsp;27.9.&nbsp;Applying a plugin with the buildscript block</b></p><div class="example-contents"><p><code class="filename">build.gradle</code></p><pre class="programlisting">buildscript {
    repositories {
        jcenter()
    }
    dependencies {
        classpath <span xmlns:xslthl="http://xslthl.sf.net" class="hl-string">"com.jfrog.bintray.gradle:gradle-bintray-plugin:0.4.1"</span>
    }
}

apply plugin: <span xmlns:xslthl="http://xslthl.sf.net" class="hl-string">"com.jfrog.bintray"</span>
</pre></div></div><br class="example-break"></div></div></div><div class="section"><div class="titlepage"><div><div><h2 class="title"><a xmlns:xslthl="http://xslthl.sf.net" name="sec:finding_community_plugins" class="section-anchor" href="#sec:finding_community_plugins"></a>27.6.&nbsp;Finding community plugins</h2></div></div></div><p>
            Gradle has a vibrant community of plugin developers who contribute plugins for a wide variety of capabilities.
            The Gradle <a class="ulink" href="http://plugins.gradle.org" target="_top">plugin portal</a> provides an interface for searching and
            exploring community plugins.
        </p></div><div class="section"><div class="titlepage"><div><div><h2 class="title"><a xmlns:xslthl="http://xslthl.sf.net" name="sec:more_on_plugins" class="section-anchor" href="#sec:more_on_plugins"></a>27.7.&nbsp;More on plugins</h2></div></div></div><p>
            This chapter aims to serve as an introduction to plugins and Gradle and the role they play. For more information on the inner workings
            of plugins, see <a class="xref" href="custom_plugins.html">Chapter&nbsp;41, <i>Writing Custom Plugins</i></a>.
        </p></div></div><div class="navfooter"><div><div class="navbar"><a xmlns:xslthl="http://xslthl.sf.net" href="multi_project_builds.html" title="Multi-project Builds - Gradle User Guide Version 3.4.1">Previous</a><span>|</span><a xmlns:xslthl="http://xslthl.sf.net" href="userguide.html" title="Gradle User Guide Version 3.4.1">Contents</a><span>|</span><a xmlns:xslthl="http://xslthl.sf.net" href="standard_plugins.html" title="Standard Gradle plugins - Gradle User Guide Version 3.4.1">Next</a></div></div></div></body></html>
gradle-doc 3.4.1-7ubuntu1 / usr / share / doc / gradle / userguide / plugins.html
