This message was deleted.

that specific error is indeed accurate - there is no “wrapper” task in subprojects, it only exists at the root project. Typically gradle is run from the root of the project tree, e.g.

./gradlew wrapper

; tasks in subprojects can be executed like

./gradlew :subproject:task

Am I alone, or do other people tangle with this problem?

Actually, I personally think most messages are quite accurate, clear, and helpful. And if I got a message that I find misleading, I open an issue on GitHub to get it changed, or a pull request that changes it. Regarding the specific case, @Chris Lee already expressed what I also would say. Just one more point, if you would do

gradle :wrapper

it would also have worked from subprojects, as you then explicitly say to run the wrapper task from the root project.

After much reflection, I think part of the problem I am experiencing is 1. We have a Big mono repo 2. It is a Big Ball Of Mud 3. I load the whole thing into IntelliJ a. This is probably a bad idea because this make IntelliJ unstable b. IntelliJ passes on some of this instability to Gradle c. The behaviour of Gradle is different under IntelliJ than from the command line i. I often see Gradle throwing ConcurrentModificationExceptions 😲 ii. I would have thought Gradle was thread-safe, but maybe running under IntelliJ it is not? 🤨 After moving to a cleaner environment, I can update the Gradle wrapper without problems. So, Gradle was in some state in my previous environment where it was unstable. Anyway, I have only been using Gradle for about a year, whereas I have used Maven since 2010. While Maven can be ugly sometimes, I find the diagnostics and support substantially more mature. I hope there is some place we can buy live support for Gradle, as it is not a good use of my time troubleshooting the many Gradle problems I encounter daily. I am meeting with some Gradle people this afternoon about Gradle Enterprise.

1. IntelliJ passes on some of this instability to Gradle

Never seen that, but well, I don't use such mono repos.

1. The behaviour of Gradle is different under IntelliJ than from the command line

Generally, this should not be the case. If you really find such problems, report to the proper place to get them fixed

I often see Gradle throwing ConcurrentModificationExceptions 😲

I've never seen it doing that and I'm using Gradle since pre-1.0. Maybe it is not Gradle but some plugin you are using?

I would have thought Gradle was thread-safe,

Should be, yes, if not, you should report it.

but maybe running under IntelliJ it is not?

Unlikely, IntelliJ just uses the tooling API to drive a Gradle daemon just like the commandline client does. (plus some code injected via init script)

After moving to a cleaner environment, I can update the Gradle wrapper without problems. So, Gradle was in some state in my previous environment where it was unstable.

Honestly, I really doubt that. I think where you test now you just test in the root project (could also be the root project of an included build if you also use composite builds). I cannot really imagine what could break to cause what you described, especially as what you described is the normal and expected behavior as we tried to explain already.

I find the diagnostics and support substantially more mature.

Well, opinions and views can majorly differ, I'm on the complete contrary side.