This message was deleted.

a shared build service would handle replacing the ‘rootproject’ coupling, with properties populated from the root project and consumed (as conventions) by subprojects.

Thanks, that's a good idea to investigate. It could also work with aggregation with self-registration cases like test-report-aggregation.

true. it isn’t clear to me that subproject -> root project (what you already have) is actually a coupling problem - the root project is always evaluated. it’s use of allprojects, subprojects, or specifically coupling subprojects together that is problematic.

yeah, I still have several cases where I had to use `subprojects`/`project(":path") { pluginManager.withPlugin(..) { .. } }` pattern to allow some kind of self-registration or adding dependencies (even if dependencies themselves use correct variants)

I just migrated our plugins to use a settings plugin instead of a root project plugin and it feels much more correct. If your shared extension is anything like ours, it is very much a settings thing.

Unfortunately if I use settings plugin from private repo I have to either declare that repo in settings or move its declaration to init script which has its own issues in heterogenic environment with different private repos for different projects. And convention plugins still would need to access common configuration somewhere.