This message was deleted.

also: is it a violation to apply a plugin to another project (subproject from root or vice versa) if its by id, not using the class reference?

The best way it to apply plugin by id, and use ...withId("...") to react on the plugin. Plugin ids are documented and they are stable while plugin classes are not documented

This might be useful https://github.com/gradle/gradle/issues/22514. Looking at this issue, I would assume it's not project isolation compatible to apply a plugin from the root module

You should currently not really care about project isolation. It is highly experimental and things you do in favor of project isolation today might be non-sense or bad practice tomorrow. But yes, it will for sure violate project isolation if you cross-configure projects. That would be like you are isolated because you have covid, but you are allowed to kiss your wife and children. Doesn't make much sense in terms of "isolation", does it? 🙂 The sense of project isolation is, that configuration for multiple projects can run in parallel and that configuration cache can be stored per project and not only per build. So any way of cross-project configuration will be a violation and I guess even each reading from the model of another project - which is bad practice anyway - will be a violation too. So no, you should neither check from one project in another project whether a plugin is applied, nor apply a plugin in another project. Even without project isolation this introduces project coupling and works against some Gradle optimizations. You probably need a settings plugin for such things. A settings plugin should (hopefully project isolation safe) be able to apply a plugin everywhere. I have a bunch of convention plugins where I have a base plugin that does really essential work that is applied by all other convention plugins. It also checks that the settings plugin is applied too by requesting a shared build service the settings plugin would have registered and set a property to

true

, as it also does essential things and the settings plugin ensures the base plugin is applied to all projects. This way it is ensured, that if anything from that convention plugins project is used, the settings plugin is applied and the base plugin is applied to all projects in the build.

Ooo i like that build service idea. That is similar to my use case. I have a convention plugin that is applied at root, which then applies more specific convention plugins to all subprojects. Like if java plugin is applied, apply pmd/checkstyle etc. This way someone cant "forget" to apply the convention plugin in one of the subprojects.

Yeah, that's bad. That is cross-project configuration which should be avoided

But with a settings plugin it would be ok?

I think so