This is important for me—my organization makes use of a distributed filesystem for home directories, with fairly restrictive quotas. This means that before people can build things with gradle, they have to set up a gradle user home on local disk, or symlinks from their gradle user home to some location on local disk.

Explaining to users how to do this is... much more difficult than it ought to be.

It also doesn't do much good for the pitch: "Hey, try this awesome build tool!... But first you'll need to perform this ugly kludge."

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!

I am not able to edit this ticket in order to provide the requested information, so I will do so in this comment. With the addition of this information, I believe that it satisfies your published guidelines, and should be considered as a feature.

Current behavior:

It is possible to configure the location of the gradle user home directory by providing it on the command-line (via -g or --gradle-user-home), by providing it as a system property (gradle.user.home), or by setting an environment variable (GRADLE_USER_HOME), via the default (usually "USER_HOME/.gradle").

Of the items that are placed under this directory, some are user-provided configuration files, like gradle.properties, init.gradle, any files under init.d, and any files a user might create for those to use.

Other items are cache directories, such as caches, native, and wrapper. These typically contain caches of information that may be re-acquired later if need be, and which can grow quite large over time.

And finally, there are job management items such as those under daemon.

Of these items, all except the user configuration files have problems in the presence of a shared filesystem for the user's home directory. The most obvious and severe is that not all shared filesystems have the same sort of locking behavior as local filesystems, resulting in very strange results when the user attempts to use daemons on more than one machine at a time. However, the caches also cause problems, since large shared filesystems often have quotas that limit the amount of storage users have in their shared space. As a result, a user may wish to place large replacable caches on local disk, away from their home directory.

At the moment, there is no way to configure where these caches and host-specific pieces live separately from where the user configuration files live. All are found under GRADLE_USER_HOME. As a result, users have a few options to work around things:

1) They can use symbolic links from their GRADLE_USER_HOME directory to directories elsewhere, so that the configuration files live under USER_HOME, but the caches are found by following the symlinks to a location under /var/tmp or the like. This also requires the user to have their login scripts ensure that the directories under /var/tmp exist after each login, in case they are clobbered (or in case the user logs into a machine that they have not previously used.)

2) They can use the GRADLE_USER_HOME environment variable to locate their entire directory (including user config files and caches both) at some location on the local filesystem, for example under /var/tmp. This also requires the user to have their login scripts ensure that this directory exists and that the user's per-user configuration files are copied into it.

Desired behavior:

Optimally, it should be possible to provide alternate locations for all of these caches directories. It's fine if they continue to be located under GRADLE_USER_HOME by default, but the ability to relocate all of the caches at once (perhaps with GRADLE_USER_CACHE which defaults to GRADLE_USER_HOME and will create the target directory if it does not exist) or the individual cache directories for each subdirectory of GRADLE_USER_HOME (so you could locate wrapper, native, daemon, and caches in different places—perhaps locating wrapper, native, and caches on a shared volume that is larger than the user's home directory, and daemon on a local volume to avoid lock and process problems.)

Since this would allow the cache location to be configured separately from the user configuration location, the user configuration might be usable to specify the cache configuration. For example, the user's gradle.properties file might specify either a new base cache dir or new individual cache dirs.

Context:

As stated in the comment I added in support of the original ticket:

This is important for me—my organization makes use of a distributed filesystem for home directories, with fairly restrictive quotas. This means that before people can build things with gradle, they have to set up a gradle user home on local disk, or symlinks from their gradle user home to some location on local disk.

Explaining to users how to do this is... much more difficult than it ought to be.

It also doesn't do much good for the pitch: "Hey, try this awesome build tool!... But first you'll need to perform this ugly kludge."

Making this easier to configure either with an environment variable or a gradle property means being able to say "add this line to your .profile" or "add this line to your .gradle/gradle.properties", instead of "run this long chunk of code in your login script that creates several directories and symlinks to them or everything will explode".

Thanks for the great write-up. The work is now tracked here: https://github.com/gradle/gradle/issues/1319