This message was deleted.

No, please open an issue, especially if you have a reproducer

yep, managed to reproduce it https://github.com/gradle/gradle/issues/19852

I'm confused that ever worked. I honestly thought you could not do that without an init script

This was introduced with the

pluginManagement { includeBuild(...) }

in Gradle 7. It was one of the goals that you could move everything from settings into a local settings plugin (except for including the settings-plugin-build and applying your settings plugin). I am surprised that there is no test case for this in Gradle’s integration test suite for this. 😞 (I might be the one who missed to add it…. 😬)

hm, then maybe the error I saw in the past was from trying to entirely replace pluginManagement with a settings plugin from an included build? It's interesting that you can have

pluginManagement { includeBuild(/* build that contributes directly to pluginManagement */) }

Yes that is tricky, but it is explicitly supported. This was the attempt to dogfood it in the Gradle build itself. And that part is working (this was never merged due to other issues): https://github.com/gradle/gradle/blob/jjohannes/idiomatic/gradlebuild/split/build-[…]in/src/main/kotlin/gradlebuild.repositories.settings.gradle.kts

when they fix this regression, and I start using it, a lot of folks are going to be really happy to see dozens of lines of pluginManagement vanish across our many builds in this large repo

i want to know what is my best strategy regarding this issue? isn't it a blocker like 7.4.1 worthy? should we wait till 7.5? or it could be a longlasting issue and i should rewrote all my configuration to be duplicated again?

It is 7.4.1 worthy, we are working on it.