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"
plugins {}
you don't use package, but rather fully qualified plugin id. Check for details in Gradle documentation docs.gradle.org/current/userguide/… – RenatoIvancic