Init script in workspace?


(Eric) #1

Hi,

I’m trying to change the Gradle cache (where the downloaded dependencies are stored) from the user home directory, to the workspace of our project. I realize this is possible with setting an environment variable, specifying -Duser.home.dir on the CLI, or using an init script. The problem with these solutions are that none of them can be checked into our source code. They all require developers to remember to set an ENV variable, write something extra on the CLI, or have an external file stored in their user home directory.

I discovered today that you can override the cache directory from within an init.gradle script, however, it doesn’t appear possible to have this file live within our workspace. Unless of course, we specify -I on the command line…

Is there a directory alongside the build.gradle, that I can place an init.gradle script and have Gradle automatically load it?

Any ideas?
Thanks


(Pepper Lebeck-Jobe) #2

I don’t have a suggestion for how you can accomplish what you are trying to accomplish.

However, in case this is a missing feature of Gradle, why do you want to do this?

I ask because it seems like a strange requirement to store this global state in a workspace local cache. Imagine, you have a developer who has cloned two copies of your project. Now, the developer will have to download all of the dependencies in both locations and lose out on part of the value of the cache.


(Mark Vieira) #3

No, but this is a common use case for custom Gradle distributions. That is, a customized version of the Gradle distribution that has your init script included in it (in an init.d directory). You can then configure the Gradle wrapper to use this distribution.


(Pepper Lebeck-Jobe) #4

In case you’d like to implement @mark_vieira’s suggestion without providing any further justification for this feature request, here is an article from October of 2012 about how to create a custom Gradle Distribution.

However, we’re always looking for feedback on how we can do a better job meeting the needs of our users. So, if you wouldn’t mind describing in a little more detail why you want the cache directory to live in the developer’s workspace, it might help inform future releases of Gradle.


(Dimitar Dimitrov) #5

One workaround you can do is change the Gradle Wrapper shell script to redefine the ${GRADLE_USER_HOME} to point to your workspace.

The downside is that then the user home stops being a central point of override and you need to sync your user properties between all workspaces (this can be trivially solved by adding a line in the gradlew script to always copy the necesarry files from ~/.gradle).


(Eric) #6

Hi guys,

Thanks for the responses. I should clarify that we are developing medical grade software. Our builds must be tightly coupled with specific dependencies, and always guaranteed to be reproducible (offline as well). We have been using a dependency locking mechanism (Netflix’s lock plugin), however, we realized recently that it misses many dependencies (pom files, and buildscript dependencies) and the ability to lock itself. Because of these problems, we got the idea of using Git LFS (on our own Artifactory) to actually store the whole Gradle cache, and remove repository declarations in our build scripts.

The idea may seem a little crazy, but I think it would 100% guarantee reproducible builds. We cache our dependencies on our own Artifactory machine, and therefore dependency download time will be negligible.

I think this feature would be really nice to have. I will take a look into the custom Gradle dist.

Thanks!


(Schalk Cronjé) #7

Have you thought of using Ivypot plugin to create a local repo?