evoking gradlew task produces never ending "....... Daemon, 1 busy Daemon could not be reused..." and add 1 to busy every line

Question

Sorry if the question title is not quality to say the least, But i am stumped at this point. Trying to update any project i have to gradle-wrapper 6.5 and up produces a cascading.

This happens regardless of what task i run in terminal, or even importing the project into Eclipse.

C:\path\to\project\dir> ./gradlew eclipse
Downloading https://services.gradle.org/distributions/gradle-6.5-bin.zip
.................................................................................................

Welcome to Gradle 6.5!

Here are the highlights of this release:
 - Experimental file-system watching
 - Improved version ordering
 - New samples

For more details see https://docs.gradle.org/6.5/release-notes.html

Starting a Gradle Daemon (subsequent builds will be faster)
Starting a Gradle Daemon, 1 busy Daemon could not be reused, use --status for details
Starting a Gradle Daemon, 2 busy Daemons could not be reused, use --status for details

And of course each Daemon is creating a java process which will not stop unless the script is terminated. And then terminate each process manually. Task Manager Screenshot

It does not occur on any other previous gradle version. Maybe someone here could point out the simple error i might have, anything honestly is a step forward at this point.

Answer 1

As upgrade is mentioned, some options of a related question seem relevant.

gradle --stop should stop all daemons of your current version. Daemons of older versions are residing in an older folder. Deleting the old version folder should avoid what is described.

Relevant gradle documentation has some details.

Flutter

I am unfamiliar with Flutter but the provided example looks to have been solved by this pull request to read with issue. It seems that some gradle properties are not set correctly.

Elsewhere, a flutter.gradle file is mentioned which I could not find in the repository. The minSdkVersion looks like the most important and it is read from flutter.minSdkVersion which might not be defined.