How to create subproject programmatically so that plugins can be added to it


I am developing a plugin that adds subprojects to the project to which the plugin is applied.
Everything is fine except one thing: when applying other plugin to the subproject it fails, because the subproject is a DefaultProject instance (I use new DP() to create it) and the getPluginManager() is unimplemented. The comment in the source code claims that decorator takes care the implementation.

What is the appropriate way to create a subproject for being able to add plugins to it programmatically?


Hi Zslot,

The only place you can create new projects is in the settings.gradle. Have a look at the implementation of Settings.include() and Settings.includeFlat() regarding how to do this. Once your settings are evaluated, the project graph is frozen and you can’t add projects. The DefaultProject instances you create are not part of the project graph and will be ignored.

If you don’t want to copy/paste code between settings scripts, you can add a plugin to the Gradle object from an init.gradle script and use it from the settings.

Here are a few starting points: (see also 42.2)

Let us know how it works out!

Hi Dimitar,

Before I react to your answer a quick side-question:
Plugin documentation claims T can be of any type. There is even an example for its usage in SettingsPluginIntegrationSpec in Gradle code.
So nice! Let’s try it and expect some magic so my subprojects can be easily set there. Nope! It fails deep in Gradle where expecting a Settings but getting a Project type instead (see stacktrace below).
Is it the regular testing setup (1) which is not suitable or something else?

(1) using ProjectBuilder and then adding via project.pluginManager.apply()


at org.gradle.api.internal.plugins.DefaultPluginManager.doApply(
at org.gradle.api.internal.plugins.DefaultPluginManager.apply(
at org.gradle.api.plugins.PluginManager$ Source)
at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(
at hu.tinca.gradle.rioplugin.Rio2PluginTest.setUp(Rio2PluginTest.groovy:20)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(
at sun.reflect.DelegatingMethodAccessorImpl.invoke(
at java.lang.reflect.Method.invoke(
at org.testng.internal.MethodInvocationHelper.invokeMethod(
at org.testng.internal.Invoker.invokeConfigurationMethod(
at org.testng.internal.Invoker.invokeConfigurations(
at org.testng.internal.Invoker.invokeMethod(
at org.testng.internal.Invoker.invokeTestMethod(
at org.testng.internal.Invoker.invokeTestMethods(
at org.testng.internal.TestMethodWorker.invokeTestMethods(
at org.testng.TestRunner.privateRun(
at org.testng.SuiteRunner.runTest(
at org.testng.SuiteRunner.runSequentially(
at org.testng.SuiteRunner.privateRun(
at org.testng.SuiteRunnerWorker.runSuite(
at org.testng.TestNG.runSuitesSequentially(
at org.testng.TestNG.runSuitesLocally(
at org.testng.RemoteTestNGStarter.main(
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(
at sun.reflect.DelegatingMethodAccessorImpl.invoke(
at java.lang.reflect.Method.invoke(
at com.intellij.rt.execution.application.AppMain.main(
Caused by: java.lang.ClassCastException: org.gradle.api.internal.project.DefaultProject_Decorated cannot be cast to org.gradle.api.initialization.Settings

Hi Zsolt,

You don’t give me much to work with :slight_smile:

Based on your stacktrace, I can see that you are trying to use the PluginManager directly from a TestNG test. From that and the questions you are asking, I dare say you are on the wrong path and are making it difficult for yourself. Try to use the Gradle Test Kit and have a look at a few other plugins before you continue adding code.

Not really any type - Plugin<Date> while syntactically correct is meaningless as the date object does not support plugins. In practice, you want to use Plugin<Project> (applied from within projects), Plugin<Gradle> (applied within init scripts), Plugin<Settings> (applied within settings - I have never used that one)

As your plugin needs to come from somewhere, unless you customize your distro, I’d suggest using Project or Gradle (you can not declare buildscript dependencies in the settings script).

I hope that helps

The stacktrace shows you are trying to apply a Settings plugin to a Project instance, which can obviously not work.