Alternative distributionUrl dependant on environment

Old Forum
1

Thanks to the joys of enterprise grade hardening the default distributionUrl is not accessible from within my company network. We would typically change this to our Nexus repository. However, on one project we are working with a 3rd party supplier that doesn’t have access to our internal network and needs to use the default.

I guess I’m looking for a solution similar to that of how I manage repositories, but I have yet to find one.

repositories {
    if( project.hasProperty('internalArtifactRepository') ){
        maven { url project.internalArtifactRepository }
    } else {
        mavenCentral()
        jcenter()
    }
}
2

You’re not the first one to wish for a solution to that problem: http://forums.gradle.org/gradle/topics/gradle_wrapper_distributionurl

3

It seems to me that there is a chicken and egg problem. What version of gradle will compile that repositories block? What if ‘mavenCentral()’ means something different in my internal gradle distribution?

I would rather not see any features added to the gradle wrapper, other than a possible ‘alternateDistributionUrl’ property. Adding any more logic than that, to cover a small percentage of configuration issues (such as the one experienced in your project…unfortunately), would be detrimental to us all. I believe the wrapper is a case of “less is more”, IMHO.

Of course, you could always hack away at the gradle wrapper code yourself and distribute your own “custom” gradle wrapper for that project. It is an unfortunate situation…

4

Hi Kevin,

Sorry for the confusion in my post. I wasn’t posting that block as a solution to this problem - merely a nice solution to a similar problem in Gradle.

I have thought about the custom wrapper approach, but because Gradle deliver so frequently the maintenance could be time consuming. We could just “settle” on a version, but the improvements and new features are sometimes too good to miss. A nice problem to have though.

I’m going to give this some more thought over the weekend and maybe come up with a solution that can result in a pull request.

5

Sounds like a plan.

To clarify my post, my projects’ environments include some very old OS’es. So, I need the gradle wrapper to stay very minimal and not add any dependencies.

Your request is perfectly valid. I was just trying to represent the other side of the argument. I trust the gradle people to do the right thing, going forward.