Import project into Eclipse with STS using Gradle wrapper ignores JVM property -Dgradle.user.home

On our corporate dev machines our user home directories are size limited thus we have to specify the Gradle home location as system env properties and/or JVM properties. When ever I import a Gradle project into Eclipse using STS and have the workspace preferences for Gradle set to use the Wrapper the gradle user home settings are totally ignored and the Gradle distribution is always downloaded into the .gradle folder in the Windows user home directoty.

Is this a known issue? Is there a work around?

Thanks Paul

Can someone confirm that this is a Gradle tooling API issue. Looking at the code I see in the class org.gradle.tooling.internal.consumer.ConnectorServices creates a DistributionFactory always using the default Gradle home thus ignoring a user set location. Does this sound like a bug?

public DefaultGradleConnector createConnector() {

ConnectionFactory connectionFactory = new ConnectionFactory(singletonRegistry.get(ToolingImplementationLoader.class));

return new DefaultGradleConnector(connectionFactory, new DistributionFactory(StartParameter.DEFAULT_GRADLE_USER_HOME));

}

It is not a Tooling API issue, you can adjust the home directory through the ‘GradleConnector.useGradleUserHomeDir’ method. So it is up to the plugin if it allows you to adjust the home directory.

As it turns out, it probaly is a tooling API issue. I just added the UI in STS to set this property and pass it on the the tooling API but the tooling API seems to only partially obey it.

In my customized gradle user home I am getting ‘daemons’ and ‘caches’ so the setting takes effect it seems. But in my default ~/.gradle folder I am still getting a folder called ‘wrapper’ to which all the distribution zips are getting downloaded.

Using tooling API version 1.3.

Related STS issue: https://issuetracker.springsource.com/browse/STS-3147#comment-80038

I can confirm what Kris said. Calling ‘GradleConnector.useGradleUserHomeDir’ does not have the desired effect. That is, it will put a few small files into the newly specified user directory (including the registry.bin of the daemon) but not the files which would be more important. That is, the artifacts are not downloaded into the new directory (although the “caches/artifacts-XX” directory is created within the new folder). This means that ‘GradleConnector.useGradleUserHomeDir’ has little use as of now.

That means this is a Gradle bug then? Is there already a corresponding issue in the Gradle issue tracker?

I would consider this as a bug, since this far from how I expect it to work. I hope a Gradle dev. can confirm this as well.

C:\Users\tmp.gradle\wrapper\dists\gradle-1.3-bin\6duudkdtsf89ftu9dh8bpgenv0\gradle-1.3-bin.zip.part (Das System kann den angegebenen Pfad nicht finden) Could not fetch model of type ‘HierarchicalEclipseProject’ using Gradle distribution ‘http://services.gradle.org/distributions/gradle-1.3-bin.zip’.

(using also this script bevore starting)

set HOME=%~dp0home set APPDATA=%HOME%\appdata set LOCALAPPDATA=%HOME%\localappdata set USERPROFILE=%HOME%\profile set HOMEDRIVE=%~d0 set HOMEPATH=%~p0 set GRADLE_USER_HOME=%HOME%\gradle set PUBLIC=%HOME%\public