Support for gradle wrapper distribution mirror


(Sam Gleske) #1

Background context

I use Nexus Repository Manager 3 to create raw proxy mirrors of software on premise for more stable build processes. Right now, I’m able to mirror all gradle and maven dependencies through Nexus. However, gradle wrapper still attempts to bootstrap gradle by downloading Gradle from the internet.

This topic has been discussed before Gradle Wrapper distributionUrl

Feature idea

I have an idea which I think would make this more desirable to the developers who would want to keep gradle wrapper simple.

Nexus and other mirrors typically support the same URL structure for distributionURL. The only difference is the domain where the files are hosted. It would be nice if one could set a GRADLE_DISTRIBUTION_MIRROR environment variable. Then, instead of attempting to download from the distributionURL defined in gradle/wrapper/gradle-wrapper.properties it would substitute the beginning of the URL with the GRADLE_DISTRIBUTION_MIRROR.

Here’s the download URL differences:

A groovy example of how this could work in gradle wrapper:

import java.util.regex.Pattern
String distributionUrl = 'https://services.gradle.org/distributions/gradle-4.1-bin.zip'
String distribution_mirror = System.getenv('GRADLE_DISTRIBUTION_MIRROR')
Pattern regex = Pattern.compile('^https?://[^/]+')
if(distribution_mirror) {
    //will remove trailing slash defined by the user in the distribution_mirror
    distributionUrl = regex.matcher(distributionUrl).replaceFirst(distribution_mirror -~ '/$')
}

//downloads from the mirror now

What are Gradle Wrapper devs’ thoughts?

Additional community benefits:

  • AWS scenario: AWS charges for transfer costs so if a build process occurs in AWS one can proxy their hosted dependencies to save on these costs through repetitive downloads of Gradle.
  • This would help reduce load on services.gradle.org by supporting a mirror. Heavy users of gradle wrapper (think entire companies) can download cached versions of Gradle instead of causing stress and load on gradle.org hosting.

(Dimitar Dimitrov) #2

You may also check this thread: Gradle wrapper in environments that require controlled builds

Soon I’ll be on this topic again and will likely fork the Gradle Wrapper to a separate project (tentative name gradle-wrapper-plus). The result would be drop-in compatible JAR that you can use in place of the standard Gradle Wrapper jar and get some extra control over the download URL. I’ll post more when I have something.


(Daryl) #3

Have you had a chance to break that out into it’s own tool/repo?


(Dimitar Dimitrov) #4

Sorry… Turns out I cannot open this - need to do a clean room which will probably wait…


(Sam Gleske) #5

I have opened a small pull request which is basically what was originally proposed in this forum discussion https://github.com/gradle/gradle/pull/6349


(Sverre Moe) #6

I am not a supporter to checking in files that can be generated
gradle/wrapper/gradle-wrapper.jar
gradle/wrapper/gradle-wrapper.properties
gradlew
gradlew.bat

Therefore the best solution would be to specify the distributionUrl within the global gradle.properties would work best. Then generating the gradle wrapper files would use that URL.


(Sam Gleske) #7

This makes an assumption that all projects build with the same version of gradle. This is not really a good assumption to make in a large environment with diverse Gradle projects.

Regarding files that can be generated. I respectfully disagree. The whole point of gradle wrapper is to self bootstrap gradle. If you don’t check in the gradle wrapper files and you need gradle to run gradle wrapper to generate the files, then that defeats the whole purpose of having gradle wrapper.

Back to the core of the subject this forum post, is about having an option to set a distribution mirror where alternative downloads of the same version of gradle can be performed.


(Dimitar Dimitrov) #8

Ok, it’s here now - a fresh take on the same old chestnut. Allows to override wrapper properties by only specifying environment variables.

Let me know how it works for you.

I’ve earmarked some improvements as well (search TODO), but they can wait for another day - it is almost 2am and I’m going to bed!


Gradle wrapper in environments that require controlled builds