What the difference in applying gradle plugin

The plugins block is the newer method of applying plugins, and they must be available in the Gradle plugin repository. The apply approach is the older, yet more flexible method of adding a plugin to your build.

The new plugins method does not work in multi-project configurations (subprojects, allprojects), but will work on the build configuration for each child project.

I would think that as functionality progresses, the plugins configuration method will overtake the older approach, but at this point both can be and are used concurrently.

---

As already mentioned by @cjstehno the apply plugin is a legacy method that you should avoid.

With the introduction of the plugins DSL, 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.

With the new plugins block method, you can add a plugin and control when to apply it using an optional parameter apply:

plugins {
    id «plugin id» version «plugin version» [apply «false»]
}

You would still use the legacy method in situations where you want to apply an already added but not applied plugin in your plugins block. E.g, in the master project a plugin xyz is added but not applied and it should be applied only in a subproject subPro:

plugins {
  id "xyz" version "1.0.0" apply false
}

subprojects { subproject ->
    if (subproject.name == "subPro") {
        apply plugin: 'xyz'
    }
}

Notice that you don't need the version anymore. The version is required in the plugins block unless you are using one of the Core Gradle plugins, such as java, scala, ...

I spent some time understanding the difference while trying to create a Spring Boot application, and that's why I am answering this again after a while. The following example for using Spring Boot plugin helped me a lot:

What should currently be used:

plugins {
  id "org.springframework.boot" version "2.0.1.RELEASE"
}

What had been used before Gradle 2.1:

buildscript {
  repositories {
    maven {
      url "https://plugins.gradle.org/m2/"
    }
  }
  dependencies {
    classpath "org.springframework.boot:spring-boot-gradle-plugin:2.0.1.RELEASE"
  }
}

apply plugin: "org.springframework.boot"

---

Now ( In Gradle 6) you can give repositories name for plugins without using build script. In settings.gradle, we can add plugin pluginManagement

pluginManagement {
    repositories {
        maven {
            url '../maven-repo'
        }
        gradlePluginPortal()
        ivy {
            url '../ivy-repo'
        }
    }
}

Reference: https://docs.gradle.org/current/userguide/plugins.html#sec:custom_plugin_repositories

---

I would like to point out though, that is it not required for a plugin to be published remotely to be able to use it! It can also be a UNPUBLISHED locally available plugin (be it convention plugins or otherwise) just as well.

In case one wishes to refer to such an unpublished locally-available plugin, you'll have to include it's so-called "build" within the desired component/build (identified via the settings.gradle(.kts)-file) like so:

pluginManagement {
    includeBuild '<path-to-the-plugin-dir-containing-the-settings-file>'
}

Afther that is done, one may use the local plugin within the plugins {}-DSL-block via its pluginId.

---