Iterate on all subprojects containing a plugin

Hi!

i have a custom plugin in my buildSrc that gathers 2 plugins i need, in my subprojects i include my custom plugin.

I configure pluginA in the subproject themselves
but pluginB is being configured in the buildSrc custom plugin as it is the same for every subproject

pluginB configuration:

npmPublish {
nodeHome.set(tasks.nodeSetup.flatMap { it.nodeDir })
packages {
register(“js”) {
version.set(“0.0.1”)
packageName.set(“coolio”)
files {
from(tasks.getByPath(“:GradlePluginTestProject1:generateTypeScript”))
from(tasks.getByPath(“:GradlePluginTestProject2:generateTypeScript”))
}
}
}
registries {
register(“nexus”) {
uri.set(uri(“http://registry”))
authToken.set(“token”)
}
}
}

my question is -
as you can see the files{} section has some hardcoded subprojects…
how can i make the files{} section be dynamically created according to all the subprojects that contains my custom plugin? (basically has the generateTypeScript task configured)

most of my subprojects doesnt have that plugin so no need to add them there.
I thought something like

subprojects.findAll { subproject → subproject.plugins.hasPlugin(‘generateTypeScript’) }

but i cant seem to figure out how to use it in the file{} section

You cannot get subprojects like that, as you also now know when the plugin is applied / when the other project get configured.

Besides that Project#plugins also should not used according to its JavaDoc.

And you also should not try to access other projects tasks like in your first code block as that is unsafe and prone to break.

At Sharing outputs between projects you can read about how to properly share task outputs between tasks.

And in your case where you do not want to configure the projects manually, you probably need to use the tactic, that for example the test-report-aggregation plugin uses. You can have a look at its sources in the Gradle sources. Basically you have a configuration where you depend on all projects, using attributes that match the attributes you use to publish this artifact in the relevant projects and then use a lenient artifact view to ignore that some projects do not provide this.