[GRADLE-2756] Not possible to specify the gradle user home to be used for all operations with the Tooling API Created: 22/Apr/13  Updated: 06/Apr/14  Resolved: 05/Feb/14

Status: Resolved
Project: Gradle
Affects Version/s: 1.5
Fix Version/s: 1.11-rc-1

Type: Bug
Reporter: Gradle Forums Assignee: Unassigned
Resolution: Fixed Votes: 2


See linked forum post.

Comment by Gradle Forums [ 22/Apr/13 ]

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.

Comment by Gradle Forums [ 22/Apr/13 ]

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

Comment by Gradle Forums [ 22/Apr/13 ]

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.

Comment by Gradle Forums [ 22/Apr/13 ]

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 '[1]http://services.gradle.org/distributi...'.

(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 PUBLIC=%HOME%\public
[1] http://services.gradle.org/distributions/gradle-1.3-bin.zip

Comment by Carlo Luib-Finetti [ 31/Mar/14 ]

This issue, reported also at "https://issuetracker.springsource.com/browse/STS-3147?jql=text%20~%20%22USER_HOME%22", is marked here as fixed. I cannot confirm. I'm using Gradle 1.11 and STS 3.5-rc.

Recently I deleted all cache directories at USER_HOME/.gradle. Then, when I started Eclipse with STS-Gradle plugin, the first action was from STS to restore all the 3rd party jars into that directory, ignoriering the settings in "gradle.properties" (which Gradle is using when I run it at command line).

Who is responsible? Gradle Tooling API oder STS-Gradle-Plugin?

Comment by Adam Murdoch [ 06/Apr/14 ]

Carlo Luib-Finetti this issue is to fix the GradleConnector.useGradleUserHomeDir() method so that the setting is honoured for everything that the tooling api does, downloading the distribution in particular.

Your issue is a different one, where something is not using the value declared in `gradle.properties` to set this value. That something might be the tooling API or it may be the STS plugin using the above method to override what the tooling API would have done by default. Could you raise a new issue in the Gradle forums, please?

Generated at Wed Jun 30 12:30:38 CDT 2021 using Jira 8.4.2#804003-sha1:d21414fc212e3af190e92c2d2ac41299b89402cf.