From mobile apps to microservices, from small startups to big enterprises, Gradle helps teams build, automate and deliver better software, faster.

Gradle Community

Is there a way to have a settings plugin that applies a plugin (id) to all projects, but that id will be resolved with the buildscript of that project?

do you mean with say `settings.gradle.lifecycle.beforeProject {}`?

I do that <https://github.com/autonomousapps/dependency-analysis-gradle-plugin/blob/main/src/main/kotlin/com/autonomousapps/BuildHealthPlugin.kt#L30-L32|here>

&gt; but that id will be resolved with the buildscript of that project?
not sure what you mean by that. I _think_ that hook uses the classloader of the projects being configured

i was trying ` settings.gradle.allprojects {}`

my settings plugin adds the plugin lib to the buildscript classpath of each project, then I am trying to apply that plugin

but the plugin lib is not a dependency of the setting splugin

you can just have the other plugin as a dependency of your settings plugin. That's how you add it to the buildscript classpath

yeah thats the thing i am trying to avoid, because my settings plugin is compiled on java 8 still for reasons, and the project plugin I want to apply is compiled on java 17. the settings plugin has a check to see if it is safe to apply that plugin first

what issue or error are you seeing with the approaches you've tried?

```Plugin with id not found```
and the stracktrace traces back to the settings plugin

and you want to make the project plugins available via the settings plugin, so you're trying to avoid forcing your consumers to put the project plugin on their classpath themselves?

it works to add it to the classpath, but then i need to apply the plugin in the actual project buildscript

can't apply it from the settings plugin it seems

&gt; my settings plugin is compiled on java 8 still for reasons, and the project plugin I want to apply is compiled on java 17
That's not so much a problem actually.
You can just tell Gradle that you know better and you want to have the Java 17 compatible variant.
As long as you don't try to compile against those classes you are fine.
Just set the jvm target version attribute for that specific dependency to 17.