First, thanks you so much for adding in init.gradle searching logic, it’s an absolute requirement in a enterprise environment.
The new documentation states:
{quote} Put a file that ends with .gradle in the GRADLE_HOME/init.d/ directory, in the Gradle distribution. This allows you to package up a custom Gradle distribution containing some custom build logic and plugins. You can combine this with the Gradle wrapper as a way to make custom logic available to all builds in your enterprise. {quote}
Can someone please expand on what “you can combine this with the gradle wrapper”? From my point of view GRADLE_HOME is exactly what we DON’T have when using gradlew, since the wrapper is going to download and create a GRADLE_HOME for us, which by definition means we don’t have control of a init.d directory. We’re using gradlew as a central place for developer and jenkins to use a sanction/tested gradle, and we need to specify our local repositories. We’ve accomplished this by tweaking the gradlew script to look for an init.gradle in the gradle/wrapper/, along side gradle-wrapper.properties. I’m imagining that something similar is going on with gradlew, but the documentation isn’t explicit.
So, exactly where would we make an init.d directory if using gradlew?
I haven’t had a chance to test this out yet, so take this with a grain of salt.
GRADLE_HOME refers to the root directory of the Gradle distrbution being used by your build, which doesn’t necessarily imply an environment variable named GRADLE_HOME.
I believe the approach that is now available is that you download the Gradle distribution, unpack it, create an “init.d” folder, and drop any init scripts in there.
Then you would drop this somewhere on your internal network, and people would point their wrappers to this custom distribution as opposed to the one from repo.gradle.org.
@andrew, that’s right. The idea is that you create a custom Gradle distribution that contains your custom ‘init.gradle’ and whatever other resources you like. You then put this distribution in some repository and point the wrapper at it.
The plan is to also allow you to specify an ‘init.gradle’ in the ‘gradle-wrapper.properties’ file, so that you can use a custom ‘init.gradle’ without needing to create a custom Gradle distribution. This might also default to some location (‘gradle/init.gradle’, say), so that you can simply follow the convention for where to put the init script.
@andrew I’ve avoided checking in the resultant GRADLE_HOME from the wrapper. To me, that sorta defeats the point of the wrapper. If I’m going to be managing the gradle binaries in source control, I might as well just have a “gradle-latest” directory and have everyone point to that instead of the wrapper, and then I’ll update it when I need. The beauty of the wrapper is that I can avoid checking binaries into source control.
Well, I look forward to seeing wrapper support for the init.gradle.
@quidryan You wouldn’t need to check in your custom Gradle distribution. You would just make the new distribution available on either an internal website or fileshare. Then your wrapper’s distributionUrl would point to, for example, file://someserver/gradle/gradle-1.0-custom.zip.
If you have a lot of projects, it would be more efficient to distribute the init.gradle in the custom distribution, as opposed to making sure the init.gradle is included with every project using the wrapper.
Still not sure if we’ll make use of this feature, but it’s nice to have the option.