I'm thinking of a gradle-cache command that would behave based on the directory it is executed in and look for a .gradle/cache directory in the current directory (so you can clean the global cache and project caches), it would have the following modes clean and info, clean would remove everything in the .gradle/cache directory, info would show you the size of the cache (for starters) this could be more elaborate and have additional options to show you what is actually in it.

Do we write the command in Java or Groovy. (Or better Python Actually I think we have to go with Java or Groovy as those can be guaranteed on a Gradle-aware installation. With Jython or JRuby, extra bits would be needed. Of course most system now come with Python installed as well as Perl – I guess Perl ois another option . I guess this means we should write a Groovy script and suffer the startup penalty.

Where would such a script go in the Gradle source tree? Perhaps we should create a place holder for experimentation.

I think what is needed to really kick this off is to create a document (by creating a TDD or BDD test perhaps?) that investigates the rules of what can be considered garbage and what must not be removed.

Is the intention for this to be a GUI-based tool, a command line tool or both?

I'd go for a command-line tool initially, GUI would be nice eventually.

I agree with the Java / Groovy as these are available.

Platform dependent executable scripts $GRADLE_HOME/bin so the command is available when the gradle command is available, no additional setup. I'd add an org.gradle.cache package that ends up in a separate jar file (=separate bundle that can be started separately when we go the OSGI way).

I think that everything can be removed in the .gradle directories except the ~/.gradle/gradle.properties file and any none gradle specific files that users may put there. But I may be wrong about this as I'm not completely aware of what is in the cache dirs.

A lot depends on the amount of control that is expected:

off the clean mode:

• clean -> clean everything
• clean group:org.junit module:junit version:<4.5 -> clean all junit versions lower than version 4.5 is this expected?

off the info mode:

• size per first level directory?
• size per group/ module?
• cached versions of each module?

As announced on the Gradle blog we are planning to completely migrate issues from JIRA to GitHub.

We intend to prioritize issues that are actionable and impactful while working more closely with the community. Many of our JIRA issues are inactionable or irrelevant. We would like to request your help to ensure we can appropriately prioritize JIRA issues you’ve contributed to.

Please confirm that you still advocate for your JIRA issue before December 10th, 2016 by:

• Checking that your issues contain requisite context, impact, behaviors, and examples as described in our published guidelines.
• Leave a comment on the JIRA issue or open a new GitHub issue confirming that the above is complete.

We look forward to collaborating with you more closely on GitHub. Thank you for your contribution to Gradle!

Thanks again for reporting this issue. We haven't heard back from you after our inquiry from November 15th. We are closing this issue now. Please create an issue on GitHub if you still feel passionate about getting it resolved.