Specify the GRADLE_USER_HOME in Windows 7

Question

How do I configure the GRADLE_USER_HOME option? My Windows username contains a space(C:\Users\Baz Foo) and I think that the build fails because of this.

E:\workspace-sts-3.0.0.RELEASE\agweb\ag-client\ag-shared\build\classes\main
error: Class com.acme.client.conn.rmi.SessionRMIImpl not found.
error: Class Foo\.gradle\caches\artifacts-13\filestore\xerces\xercesImpl\2.1
0.0\jar\9161654d2afe7f9063455f02ccca8e4ec2787222\xercesImpl-2.10.0.jar not found
.
error: Class Foo\.gradle\caches\artifacts-13\filestore\xml-apis\xml-apis\1.4
.01\jar\3789d9fada2d3d458c4ba2de349d48780f381ee3\xml-apis-1.4.01.jar;C:\Users\Baz
not found.
error: Class Foo\.gradle\caches\artifacts-13\filestore\provided\jbpm\3.0.4\j
ar\f2a9f8f32e59b335e069b5444f6c36a30abf0845\jbpm-3.0.4.jar;C:\Users\Baz not fou
nd.
error: Class Foo\.gradle\caches\artifacts-13\filestore\log4j\log4j\1.2.16\bu
ndle\7999a63bfccbc7c247a9aea10d83d4272bd492c6\log4j-1.2.16.jar;C:\Users\Baz not
found.
5 errors ...

I have added an environment variable GRADLE_USER_HOME and set it to C:\Users\Baz Foo\.gradle and tried also with --gradle-user-home="C:\Users\Baz Foo\.gradle" but none of them work.

Answer 1

I have explicitly defined GRADLE_USER_HOME to point to a path without spaces(for example: E:\gradle-repository). The gradle-repository folder contains the initialization script(init.gradle file, see Gradle initialization scripts).

Answer 2

Just configure it to a directory of your choice (and out of your system drive, may be) according to recommendations here

Allow the location of the Gradle cache to be specified independent of the user configuration files, which it cite below.

You may want to change your init scripts, too :

Initialization Scripts

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:

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.) 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".