[GRADLE-2690] Make Gradle artifact cache portable (make cache paths relative to cache base) Created: 22/Feb/13 Updated: 06/Feb/17 Resolved: 06/Feb/17 |
|
| Status: | Resolved |
| Project: | Gradle |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Improvement | ||
| Reporter: | William Price | Assignee: | Unassigned |
| Resolution: | Duplicate | Votes: | 24 |
| Description |
|
My company requires that we be able to escrow our software. This requires us to build a package that includes everything necessary to build, including 3rd-party libraries, without assuming that any particular network resources are available. To satisfy this requirement, I need to be able to package the Gradle artifact cache (e.g. the entire GRADLE_USER_HOME) and then use it on another machine (which I may not be able to control) and have the cached artifacts resolve successfully in --offline mode. Since Gradle's cache stores the native OS absolute path (e.g. drive letters "C:" and backslash() file separators in the case of Windows) it will not work if unpacked into a different drive letter and/or directory structure. Similarly, the cache cannot be moved between a Windows and *NIX environment. (Our build process supports running under both Linux and Windows.) Without necessarily changing any of the external behaviors/interfaces it would be fantastic if the artifact cache stored paths *relative to the cache base directory* and normalized to always use '/' as the file separator. Please note that this request is NOT asking to change the outwardly-visible behavior of the cache; i.e. existing APIs could still return runtime-resolved absolute paths. If this were done, it should be much easier to move the contents of GRADLE_USER_HOME to a new location/machine without needing to rebuild, as long as GRADLE_USER_HOME is set (at the destination) to point to the correct location. This approach has worked for Maven-based projects and in contrast makes escrowing a Gradle build very painful. |
| Comments |
| Comment by Jon McKenzie [ 03/Oct/14 ] |
|
+1 We have a similar vendoring requirement. |
| Comment by Anton [ 16/Sep/15 ] |
|
+1 |
| Comment by Marko Krajnc [ 11/Jul/16 ] |
|
+1 |
| Comment by James French [ 04/Aug/16 ] |
|
+1 Would really like this. |
| Comment by Silvio Moioli [ 31/Aug/16 ] |
|
+1 |
| Comment by Andrea Panattoni [ 04/Oct/16 ] |
|
+1 |
| Comment by Mihai CAZACU [ 20/Oct/16 ] |
|
+1 |
| Comment by Benjamin Muschko [ 15/Nov/16 ] |
|
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:
We look forward to collaborating with you more closely on GitHub. Thank you for your contribution to Gradle! |
| Comment by James French [ 15/Nov/16 ] |
|
I still want this. The use case for me is that I want to manage the gradle distribution and plugins centrally and have it checked in to source control where it has visibility tracking. All users would run with --offline. It is not possible to run with --offline if people have their gradle distro checked out to different places. If the cache did not store absolute paths this would work. |
| Comment by Sebastian Schuberth [ 15/Nov/16 ] |
|
Same here, we want to pre-populate the cache on newly added CI nodes by copying over the cache from some other node, which potentially stores the cache in a different absolute directory. |
| Comment by Silvio Moioli [ 16/Nov/16 ] |
|
+1, still relevant. |
| Comment by Marko Krajnc [ 16/Nov/16 ] |
|
Still relevant => open a new GitHub issue! |
| Comment by Paulo R C Siqueira [ 16/Nov/16 ] |
|
Definitely still relevant! |
| Comment by Benjamin Muschko [ 06/Feb/17 ] |
|
The issue is now tracked via https://github.com/gradle/gradle/issues/1338. |