I have the following:
~/.gradle/init.gradle

allprojects {
repositories {
maven {
url = 'http://mydomain/nexus/content/groups/public'
}
}
buildscript {
repositories {
maven {
url = 'http://mydomain/nexus/content/groups/public'
}
}
}
}

webapp-parent.gradle

buildscript {
dependencies {
classpath group: 'org.gradle.api.plugins', name: 'gradle-tomcat-plugin', version: '0.9.8'
}
}

apply plugin: org.gradle.api.plugins.tomcat.TomcatPlugin

build.gradle

apply {
from 'webapp-parent.gradle'
}

Now, when I run the webapp-parent.gradle, it works:

$ ./gradlew -b webapp-parent.gradle
Download http://mydomain/nexus/content/groups/public/org/gradle/api/plugins/gradle-tomcat-plugin/0.9.8/gradle-tomcat-plugin-0.9.8.jar
...
BUILD SUCCESSFUL

but when I run the build.gradle file, it fails:

$ ./gradlew

FAILURE: Build failed with an exception.

• Where:
  Build file '/home/wujek/IdeaWorkspace/gradle-test/build.gradle' line: 1

• What went wrong:
  A problem occurred evaluating root project 'gradle'.
  > Could not resolve all dependencies for configuration 'classpath'.
  > Could not find org.gradle.api.plugins:gradle-tomcat-plugin:0.9.8.
  Required by:
  unspecified:unspecified:unspecified

What am I doing wrong?

wujek

As background, here is what I am trying to achieve:
1. have a single place where all repositories are defined, and which point to our nexus - it should be global, not per build
2. have a parent boilerplate build file that applies some plugins, in this case, the gradle-tomcat-plugin
3. have all webapps apply the parent build and be able to use its configuration, classpath and so on and only refine the configuration as the webapps need it

wujek

I've voted for this issue as well. In our organization, we're (unfortunately) a maven shop and its been a struggle trying to convince the powers that be that gradle should be an acceptable build tool we can onboard with. Not being able to externally/globally configure the repository(s) to use (and any authentication credentials) for all gradle project buildscript dependencies just adds more fuel for the naysayers to claim gradle is not ready in our organization.

This in fact just came up the other day as we are in the process of changing to a different nexus repository and word got out that there are proof of concept gradle builds running in our CI environments that broke because the hardcoded URLs in the project build.gradle files needed to be changed. And sure, enough a whole flame war started up where people said things like this is exactly why gradle is not ready for prime time.... Sigh.

is there any known workaround for this to achieve this behaviour at the moment?

Another +1. We've got a local artifactory here, and specifying it all over the place is a massive pain.

Alternately, a simple way to specify a that a local repo is a mirror of various public ones in a single place that is used by all build script blocks in a project would help. That would probably be covered by e.g. GRADLE-712, and may be somewhat easier to implement as it wouldn't require changing build script resolution stuff.

+1 for us. We got a local ivy repo.

@Dan, did you find a workaround?

Another +1. We have the same use case as the OP.

Another +1. We are using a internal Artifactory where anonymous access is disabled. I endend up defining the repo URL three times in build script (buildscript, repositories, artifactoryPublish) with credentials. This bloths up the build script and maintenance is very hard. Having global repo definitions would be very nice!

+1. I'm hard coding the repository and artifactoryPublish URLs inside a custom plugin, but the plugin itself resides on our local artifactory... thus every buildScript{} block still needs to know the exact URL.

It's a pitty that this can be done easily in maven, and it's not possible to do that gradle

Is a shame this one is still out there (along with Provided/Optional configurations)

I find it hard to apply other plugins via a master corporate plugin, or to use init scripts to do the same. And I imagine this not being too tough of a fix.

+1, same use case

big issue

+1

I am surprised this is still not planned.

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:

• Checking that your issues contain requisite context, impact, behaviors, and examples as described in our published guidelines.
• Leave a comment on the JIRA issue or open a new GitHub issue confirming that the above is complete.

We look forward to collaborating with you more closely on GitHub. Thank you for your contribution to Gradle!

This is an important issue in our case. We have tens of projects that all have to be updated if anything to do with the repository access change.

Migrated to https://github.com/gradle/gradle/issues/1323

I have added this to our Backlog for consideration as it is one of the most highly voted issues.

From Adam on GitHub:

This is quite doable now:

Create a script plugin that contains the repository definitions.
Use this in each script plugin:

buildscript {
apply from: 'repos.gradle', to: buildscript
dependencies

}