0

My gradle project looks like this:

Root project 'multiproject'
+--- Project ':foo1'
+--- Project ':foo2'
+--- Project ':bar'

Is it possible to apply a closure (from a root project) to only some subprojects, excluding specified one(s), like you can do with subprojects {...} to all of the subprojects?

In case of my project, I want to apply a plugin to subprojects :foo1 and :foo2, without applying it to project :bar. How can I do that without repeating the closure or adding plugin to each subproject manually?

My project uses Groovy for Gradle scripts, but both Kotlin DSL and Groovy syntax is ok for me.

I have tried using project ("name") {} and subprojects {} closures, but I coudn't apply it to multiple or exclude some of the projects using the syntx I know.

aSemy
  • 5,485
  • 2
  • 25
  • 51
Nik
  • 1
  • 3
  • The Gradle idiomatic way of conditionally applying configuration is to [avoid using `subprojects {}` and `allprojects{}`](https://docs.gradle.org/current/userguide/sharing_build_logic_between_subprojects.html#sec:convention_plugins_vs_cross_configuration), and instead use [convention plugins](https://docs.gradle.org/current/samples/sample_convention_plugins.html). [This answer](https://stackoverflow.com/a/71892685/4161471) how to set them up using [buildSrc](https://docs.gradle.org/current/userguide/organizing_gradle_projects.html#sec:build_sources). – aSemy Apr 24 '23 at 11:25
  • The thing is that I am forking another project where `subprojects {}` logic is used. I am adding another subproject to it, which needs a plugin that conflicts with another plugin used across rest of the project. I do not want to make the changes that would make the fork too different and hard to maintain, and Gradle script rewrite like this will make upstream dependencies version changes hard to update. – Nik Apr 24 '23 at 16:12
  • Actually I have come up with the solution thanks to your comment. I can use both conventional plugins and subprojects logic, keeping the stuff that is frequintly changed in the upstream in the `subprojects {}` block, and moving the plugins and their configuraion to conventional logic. – Nik Apr 24 '23 at 16:28
  • Only with a caveat: `dependencies {}` block needs one of the two plugins to function, I still had to move it to conventional logic. – Nik Apr 24 '23 at 16:48

0 Answers0