This message was deleted.

I don't think there's any need for a reproducer at this point. > He just doesn't understand why you would ever do that? I don't think that's the case. I think the team doesn't understand the specific problem with Kotlin locks in buildSrc, so it might be useful if you could clarify that particular problem. The other issues seem pretty clear to me. It would also be helpful if you could clarify what "should do what I mean" actually means in the issue. There are a bunch of way to interpret that statement.

Obviously the team doesn't understand that that's not a problem.... If the team doesn't understand that You need to run wrapper with write locks if you're using locks with build source... Then that's a problem. They need to understand how locks work and how the kotlin build if that's the case. I guess maybe they should try adding locks to build source and then doing some updates with wrapper without updating the locks when they do it. Wait till they see The kotlin locks blow up.... I don't know I don't have time for this. This script should not need to exist. Somehow though you've all become focused on the one thing that actually works as expected. Well, at least as expected as you can get when you realize that Gradle is adding kotlin dependencies to your build source

> maybe they should try adding locks to build source and then doing some updates with wrapper without updating the locks when they do it. Wait till they see The kotlin locks blow up I would use that as the reproducer.