Third-party plugins cannot be applied by ID from external build scripts

[bmuschko]

Original issue: https://issues.gradle.org/browse/GRADLE-2136

Expected Behavior

An external plugin can be applied in a script plugin by ID. The plugin can be added to the build script's classpath and applied with the plugins DSL or the buildscript block.

Current Behavior

An external plugin can only be applied in a script plugin by type. If applied in a script plugin an exception is thrown saying that the plugin cannot be found.

* What went wrong:
A problem occurred evaluating script.
> Plugin with id 'com.bmuschko.tomcat' not found.

Context

This is an unnecessary limitation of Gradle's plugin system. Users run into the issue all the time. The limitation is not documented.

Steps to Reproduce (for bugs)

build.gradle:

apply from: 'script.gradle'

script.gradle:

buildscript {
    repositories {
        jcenter()
    }

    dependencies {
        classpath 'com.bmuschko:gradle-tomcat-plugin:2.2.5'
    }
}

apply plugin: 'com.bmuschko.tomcat'

Another manifestation:

//build.gradle
buildscript {
  repositories { ... }
  dependencies {
    classpath "org._10ne.gradle:rest-gradle-plugin:0.4.2" //any external plugin can be used
  }
}

apply plugin: "org.tenne.rest"

task fromMain(type: org._10ne.gradle.rest.RestTask) { //works fine
  //...
}

apply from: 'gradle/other.gradle'

//other.gradle
task fromOther(type: org._10ne.gradle.rest.RestTask) { //fails
  //...
}

FAILURE: Build failed with an exception.

* Where:
Script '/tmp/plugin-class-other-script/gradle/other.gradle' line: 1

* What went wrong:
A problem occurred evaluating script.
> Could not get unknown property 'org' for root project 'plugin-class-other-script' of type org.gradle.api.Project.

[ghale]

Big +1 to this. Another (related) place where this is an issue is init scripts.

[pioterj]

I think that rather than fixing this issue we should address remaining gaps and un-incubate new plugin DSL. As a part of that we should allow the plugins block in all script types including script plugins.

[bmuschko]

@pioterj That would be another option. The buildscript is just one example. The same is true for the plugin DSL. We'd also need to lift some additional limitation the plugin DSL still has e.g. the ability to be applied in subprojects or allprojects - a common use case how script plugins are applied.

[pioterj]

We'd also need to lift some additional limitation the plugin DSL still has

Yes, that's what I meant by addressing the remaining gaps.

e.g. the ability to be applied in subprojects or allprojects

This is already available.

[BrainStone]

Having this fixed would be highly appreciated!

[szpak]

Probably the same root cause as #1894 (Unable to refer classes from extenal plugins in other *.gradle files).

[bzon]

Is there any update for this? I'm trying to use the OWASP dependency check plugin in an external gradle script because we have hundreds of repositories and we don't want to include it in all the build.gradle files in each repo.

This is the plugin - https://github.com/jeremylong/dependency-check-gradle

I'm getting this when the following is added to an external gradle script.

external-script.gradle:

buildscript {
    repositories {
        mavenCentral()
    }

    dependencies {
        classpath "org.owasp:dependency-check-gradle:2.1.1"
    }
}

allprojects {
    apply plugin: 'org.owasp.dependencycheck'
}

Error:

* What went wrong:
A problem occurred evaluating script.
> Plugin with id 'org.owasp.dependencycheck' not found.

[yetanotherion]

@bzon your issue may be fixed by putting

apply plugin: org.owasp.dependencycheck.gradle.DependencyCheckPlugin

Instead of

apply plugin: 'org.owasp.dependencycheck'

https://github.com/jeremylong/dependency-check-gradle/blob/master/src/main/resources/META-INF/gradle-plugins/org.owasp.dependencycheck.properties

[mesibo]

Any update on this issue. Fixing this issue will help maintain organization wide gradle files which can be directly imported (apply from) into new projects.

[emersonf]

Any update on the status of this?

@wilkinsona have you seen this before? I tried to put dependencyManagement in a build script shared by multiple microservices projects via apply from:, but io.spring.dependency-management then doesn't resolve.

[bric3]

Following a discussion on twitter with @melix on how to improve error message, in this case that the plugin with id cannot be found :

problem configuring root project 'edited'
…
Caused by: org.gradle.api.plugins.UnknownPluginException: Plugin with id 'org.springframework.boot' not found.

I propose the exception message suggest possible reasons for the error to happen, in this case one of the reason is this issue. Gradle could fail with a message like this (à la Mockito)

Plugin with id 'org.springframework.boot' not found.

This can happen for (but not limited to) the following reason :
  - There's a typo in the plugin id
  - The plugin id changed, make sure the plugin id is correct on https://plugins.gradle.org/
  - Gradle cannot use plugin ID with external (shared) build scripts. => https://github.com/gradle/gradle/issues/1262
  - Gradle cannot use plugin ID from initscript => https://github.com/gradle/gradle/issues/1322

Also in this regard the website https://plugins.gradle.org/ could link to these issues where the plugin id cannot be used. Also it could be useful to also describe the way to apply a plugin with the class (with a warning of course).

[Vampire]

The same is also true for settings.gradle.
I reported this at https://discuss.gradle.org/t/applying-a-plugin-by-alias-to-settings-gradle/7387 and also provided a self-contained example.
@breskeby started to look at it, but unfortunately at some point in time stopped responding completely
For settings script it indeed was fixed in 1.12 it seems.
My reproducer that reproduces the issue with 1.11 works fine with 1.12.

[italobb]

@emersonf Instead of :

apply plugin: 'io.spring.dependency-management'

use

apply plugin: io.spring.gradle.dependencymanagement.DependencyManagementPlugin

You need to refer to the implementation-class when you're applying a plugin using an external script.

[voddan]

Looks like this bug is not going to be fixed for a while.

Can we at least improve the error message? Something like:

Plugin with id 'io.spring.dependency-management' not found. 
If in external script pluginn, try refering to it by its class name `io.spring.gradle.dependencymanagement.DependencyManagementPlugin`

[guenhter]

Really looking forward to see this fixed. Took two hours of my time today...

[Bluexin]

We'd also need to lift some additional limitation the plugin DSL still has

Yes, that's what I meant by addressing the remaining gaps.

e.g. the ability to be applied in subprojects or allprojects

This is already available.

So I know this is fairly old, but I've ran into issues trying to use the plugin DSL in allprojects/subprojects with Kotlin build scripts :

* What went wrong:
The plugins {} block must not be used here. If you need to apply a plugin imperatively, please use apply<PluginType>() or apply(plugin = "id") instead.
> The plugins {} block must not be used here. If you need to apply a plugin imperatively, please use apply<PluginType>() or apply(plugin = "id") instead.

Using

------------------------------------------------------------
Gradle 4.10.2
------------------------------------------------------------

Build time:   2018-09-19 18:10:15 UTC
Revision:     b4d8d5d170bb4ba516e88d7fe5647e2323d791dd

Kotlin DSL:   1.0-rc-6
Kotlin:       1.2.61
Groovy:       2.4.15
Ant:          Apache Ant(TM) version 1.9.11 compiled on March 23 2018
JVM:          1.8.0_181 (Eclipse OpenJ9 openj9-0.9.0)
OS:           Windows 10 10.0 amd64

Should I make a separate issue for it on the kotlin dsl repo?

[Vampire]

Note that the apply plugin: is not followed by a quoted string but by a literal.

@ahakanbaba not really, it can be followed by both.
If it is followed by a string, that string has to be the ID of the plugin.
If it is followed by a class (doesn't matter whether fully-qualified or whether you use an import) that plugin class is applied.

[jjohannes]

Note that it is now recommended to use the plugins {} DSL and pre-compiled script plugin (convention plugins) in buildSrc where this all works well.

Example: https://docs.gradle.org/6.7-rc-2/samples/sample_convention_plugins.html

[Vampire]

But that doesn't make this issue less a bug, does it?
And even more specifically, can you tell me how I use the plugins block works since Gradle 6.0
or even a buildSrc class in the settings script? ;-) [#1262 (comment)] worked until 6.0, since then buildSrc classes cannot be used in settings scripts anymore, but since 7.0 you can instead use a settings plugin from an included build using pluginManagement { includeBuild(...) }

[figroc]

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

Future versions of Gradle will remove this restriction.

Is there any plan to lift this restriction?

[szpak]

I bumped into that once more. The problem is still valid with 7.4.2. Sometimes, it makes Gradle scripts separation slightly harder.

[oscarnylander]

For reference, if you're looking to apply a plugin by implementation class in the Kotlin DSL, you'll have to use the following syntax:

apply<com.example.package.of.ImplementationClass>()

instead of

apply(plugin="com.example.package.of.ImplementationClass")