Applying a plugin by id in settings.gradle


(Tilo Dickopp) #1

I’m running into a minor problem, when applying a plugin in ‘settings.gradle’, running Gradle 1.8. When I apply it like this:

apply plugin: 'my-plugin'
  buildscript {
    repositories.maven { url 'http://11.22.33.44/artifactory/plugins' }
    dependencies.classpath 'com.mycompany:myplugins:1.0.0'
}

I get this error:

* What went wrong:
A problem occurred evaluating settings 'main'.
> Plugin with id 'my-plugin' not found.
  * Try:
Run with --info or --debug option to get more log output.
  * Exception is:
org.gradle.api.GradleScriptException: A problem occurred evaluating settings 'main'.
        at org.gradle.groovy.scripts.internal.DefaultScriptRunnerFactory$ScriptRunnerImpl.run(DefaultScriptRunnerFactory.java:54)
        at org.gradle.configuration.DefaultScriptPluginFactory$ScriptPluginImpl.apply(DefaultScriptPluginFactory.java:132)
        at org.gradle.initialization.ScriptEvaluatingSettingsProcessor.applySettingsScript(ScriptEvaluatingSettingsProcessor.java:64)
        [...]
        at org.gradle.launcher.bootstrap.ProcessBootstrap.run(ProcessBootstrap.java:32)
        at org.gradle.launcher.GradleMain.main(GradleMain.java:23)
Caused by: org.gradle.api.plugins.UnknownPluginException: Plugin with id 'my-plugin' not found.
        at org.gradle.api.internal.plugins.DefaultPluginRegistry.getTypeForId(DefaultPluginRegistry.java:82)
        at org.gradle.api.internal.plugins.DefaultPluginContainer.getTypeForId(DefaultPluginContainer.java:99)
        at org.gradle.api.internal.plugins.DefaultPluginContainer.apply(DefaultPluginContainer.java:34)
        at org.gradle.api.internal.plugins.DefaultObjectConfigurationAction.applyPlugin(DefaultObjectConfigurationAction.java:101)
        at org.gradle.api.internal.plugins.DefaultObjectConfigurationAction.access$200(DefaultObjectConfigurationAction.java:32)
        at org.gradle.api.internal.plugins.DefaultObjectConfigurationAction$3.run(DefaultObjectConfigurationAction.java:72)
        at org.gradle.api.internal.plugins.DefaultObjectConfigurationAction.execute(DefaultObjectConfigurationAction.java:114)
        at org.gradle.groovy.scripts.DefaultScript.apply(DefaultScript.java:91)
        at org.gradle.api.Script$apply.callCurrent(Unknown Source)
        at settings_6m70vs06evv92jp7124mju1vbd.run(C:\Data\p4workspace\COMMON\core.3\settings.gradle:1)
        at org.gradle.groovy.scripts.internal.DefaultScriptRunnerFactory$ScriptRunnerImpl.run(DefaultScriptRunnerFactory.java:52)
        ... 29 more

The ‘META-INF/gradle-plugins/my-plugin.properties’ file seems to be fine, and when I use the class name, it works:

apply plugin: com.mycompany.MyPlugin

In the same Jar I have a couple of plugins that are applied to ‘Project’, and all of them work as expected.


(Szczepan Faber) #2

Hey,

Did you try to apply this plugin in a regular build.gradle file?


(Szczepan Faber) #3

I thought about this a bit more.

I haven’t seen a use case for applying plugins in settings.gradle, yet. Typical Gradle plugin is an object that is a applied to a ‘project’ instance (e.g. implements Plugin) . In settings.gradle, there’s no ‘project’ instance yet, because the it’s the settings.gradle that defines the projects.

You can try writing the plugin that implements Plugin and apply it in the settings.gradle. I cannot try it out right now and I’m not sure if that’s what you want.

The bottom line is that you cannot use a regular plugin in settings.gradle because regular plugin are intended to be applied to ‘project’ instances.

Hope that helps!


(René Groeschke) #4

Hi Tilo, I was able to reproduce this issue. It seems that applying a plugin by id does only work when resolved from the buildSrc project. I’ve raised GRADLE-2914. As a workaround you should apply the plugin by class for now.

thanks for reporting!

cheers, René


(Matias Bjarland) #5

For a use case for aplying plugins in settings gradle:

http://forums.gradle.org/gradle/topics/while_we_are_waiting_for_plugins_in_settings_gradle

http://issues.gradle.org/browse/GRADLE-2066

i.e. the use case is that we would like to add conventional patterns to how multi-project builds are configured. We have a third party application framework with its own concept of projects, its own way of generating classpaths, etc etc. We then have a ‘plugin’ which gets executed in settings.gradle and which creates a multi-project structure mirroring the third party project structure in gradle.

AFAIK, the only place to set up multi-project structures in gradle is settings.gradle, thus this code would have to get executed there.


(Tilo Dickopp) #6

Thank you for the quick reply, everyone!

My use case is the one described by Matias:

  • We have a large number of projects: P1, P2, …, PN * For every customer we deploy a different combination of those projects in our data center. For example customer 1 might get P1 and P2, and customer 2 might get P2 and P3. We also have a nice way to look up the projects needed by a customer programmatically. * Now, I’m in the process of writing a custom settings-plugin, and then I want to create a root project for every customer. These root projects will use the plugin to determine what projects are needed and where they are in the filesystem. Basically, this will be a bipartite graph with root projects on one side connected to projects that implement functionality on the other side.