https://gradle.com/ logo
Join Slack
Powered by
another question re: Isolated Projects. A common p...
# plugin-development
c
another question re: Isolated Projects. A common pattern we currently use is: 1. Apply a plugin to the root project, which then: 2. Ensures another plugin is applied every other project We often need this because we want to do something on every Java project, like adding some sort of check or task. We could manually apply the plugins in the buildscript of each project, but this makes it really easy for our devs to forget to add the plugin if they add a new project. It seems this becomes even more necessary to do for Isolated Projects, as you need to make so many variants/configurations in other projects rather than just accessing their state from elsewhere. However, isn’t using the root project to apply plugins other every other project modifying the state of those projects? Isn’t this disallowed? If so, is there some other way to automatically apply a plugin to every project?
m
This is disallowed indeed, there are multiple issues about adding proper ways to do this but none is available today AFAIK, let me dig
THis is probably the main tracking issue: https://github.com/gradle/gradle/issues/22514
👀 1
And apparently, I was wrong (and I forgot I already asked the same question at the time 🙈 ) You can use 
beforeProject{}
to apply a plugin to all projects https://github.com/gradle/gradle/issues/22514#issuecomment-2099179052
Copy code
gradle.lifecycle.beforeProject {
  pluginManager.apply("java")
}
gradle.lifecycle.afterProject {
  println("Is it java? ${extensions.findByName("java")}")
}
c
interesting… would that be from a settings plugin, or still in the root project?
m
I'm not sure TBH, I have a very hard time wrapping my brain around this
c
feels like it would make more sense in settings plugin, as otherwise it would not apply to the root project before it is evaluated
m
Probably
c
the only issue is that settings plugins are footguns with all the buildscript classloader issues, so need to be very careful and probably produce a separate jar just to use in the settings plugin with no deps… for every plugin bundle
➕ 1
I guess one could write a settings plugin that reads a list of plugin ids to apply to every project from a file, then if you’re in my situation (100s of plugins published from 100s of repos) you don’t need every one of these to make a settings plugin jar
m
Agreed. I personally try to avoid settings plugins as much as possible
My current solution is convention plugins. For any non-trivial builds I have, every project in is required to apply a convention plugin and I do the common configuration there
v
In our corporate convention plugins I have a settings plugin and various convention plugins. Each of the convention plugins does apply the the 
com.company.base
plugin that does stuff that should be done in every project. The 
com.company.base
plugin verifies that the settings plugin is applied (via a boolean in a shared build service that the settings plugin sets to 
true
) and the settings plugin verifies that in each and every project the 
com.company.base
plugin is applied. This way I ensure that if any project applies any plugin of the convention plugins, all projects apply any of the convention plugins and the settings plugin is also there to do its work. Previously I had the settings plugin apply the base plugin to all projects that do not have it automatically. (With conventional ways, still on Gradle 7.x mainly here for reasons 😞) But that had other problems, as soon as the base plugin added a 3rd party plugin that uses 
afterEvaluate
as the time those were applied were at a stage where 
afterEvaluate
is no longer allowed.
c
these are all great ideas, thanks
Open in Slack
PreviousNext
Powered by