[GRADLE-424] Create gradle_cache command to manage $HOME/.gradle Created: 22/Mar/09  Updated: 10/Feb/17  Resolved: 10/Feb/17

Status: Resolved
Project: Gradle
Affects Version/s: None
Fix Version/s: None

Type: New Feature
Reporter: Russel Winder Assignee: Unassigned
Resolution: Won't Fix Votes: 2

Issue Links:
Duplicated by GRADLE-1908 Gradle should expire and prune old en... Resolved


Some people like to keep their Maven and Ivy caches relatively clean and tidy – often, for example, by doing a "rm -rf ~/.m2/repository" : Maven has no cache management mechanism which makes this the easiest technique. It would be good if Gradle went one stage further than having "rm -rf ~/.gradle/cache" as the equivalent technique. Having a way of actively managing the Gradle cache would be good for people who like to keep things trim.

Comment by Tom Eyckmans [ 22/Mar/09 ]

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.

Comment by Russel Winder [ 23/Mar/09 ]

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?

Comment by Tom Eyckmans [ 23/Mar/09 ]

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?
Comment by Benjamin Muschko [ 15/Nov/16 ]

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!

Comment by Benjamin Muschko [ 10/Feb/17 ]

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.

Generated at Wed Jun 30 11:29:45 CDT 2021 using Jira 8.4.2#804003-sha1:d21414fc212e3af190e92c2d2ac41299b89402cf.