I am not convinced by this. I think per project cache material should be in the project directory as they are now. Only per user, non-project-specific things should go in $HOME/.gradle.

Adding .gradle to the ignore list in .bzrignore, .gitignore or .hgignore stops changes being notified or committed.

Can I suggest that if your version control client doesn't have an ignore capability, then changing your client is probably the best way forward?

In other words you prefer to give additional work to the user (who has to add ignore rules for .gradle at each place where he uses Gradle) rather than to do additional work in Gradle itself to avoid to pollute each directory where Gradle is used?

An alternative would be to use the tmp directory. This is a good place as well to avoid to generate garbage everywhere.

In this case yes. There are times when the user knows best. This user (i.e. me wants all things directly associated with a project to be held all in one place. This enables me to move the directory arbitrarily in the filestore and, more importantly, across machines in confidence that there is no other material I need to be moving. I am prepared to pay the cost of having to manage the .XXXignore file to have this ease of use feature.

Of course, if the material is purely transitory, i.e. there is no real need for it to be persistent, then your suggestion of /tmp is actually better than either the current situation or $HOME/.gradle.

/tmp is fine for me

As with the other issue, we have to discuss this on the dev list. There has been a similar complaint about that by another person. Going to a non-project folder is not without issues. This is an 0.7 issue.

I know this conversation is a little old but what was the resolution for this? I don't see any option for moving the $buildDir/.gradle directory to anywhere else as of 0.9rc-1.
I'd like to be able to have this directory created in /tmp or the project's build directory. We have a policy at my company that a build should not create or modify anything in the source directory.
Would it be possible to make this a command line option?

The issue was filed when Gradle created a .gradle for every directory of a Gradle build. Now the .gradle is created only in the root. But we also want to move this directory into user home. Therefore I reopen this issue.

I would also like to be able to move the .gradle directory (while I do agree $HOME/.gradle isn't the right place for it, I don't want it polluting my source tree either, especially not the root directory).

I personally prefer that nothing is written to my source tree that does not get committed, for lots of different reasons.
It helps keep my source tree sane, the OCD part of me hates to see a cluttered root directory and I frequently like to have all build output go to a ram drive.

Doesn't the "--project-cache-dir" command line argument address this issue? It doesn't put the files in $HOME/.gradle, but it lets you specify where you want them put.

(Yes, I realize this is an old conversation...)

Yes, "--project-cache-dir" does address this from the command line. But that requires the caller to specify it. Is there a way to set this from a build.gradle file?

For example, there are the project properties buildDir and projectDir (see Table 13.1. Project Properties in Section 13.2.1. Standard project properties in the user guide for gradle 1.7 at http://www.gradle.org/docs/current/userguide/writing_build_scripts.html). It would be nice if there was a property projectCacheDir (I tried; there's not) that I could set in relation to buildDir, rather than having this always be ${projectDir}/.gradle (apologies if that's not the right notation – I'm new to both gradle and groovy) unless overridden on the command line.

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.