[GRADLE-2801] Allow specifying global buildscript classpath repo from init script for script plugins Created: 20/Jun/13  Updated: 03/Feb/17  Resolved: 03/Feb/17

Status: Resolved
Project: Gradle
Affects Version/s: None
Fix Version/s: None

Type: Improvement
Reporter: Gradle Forums Assignee: Unassigned
Resolution: Duplicate Votes: 51


There's no way to inject this from the outside, therefore no way to do it from an init script.

Comment by Gradle Forums [ 20/Jun/13 ]

I have the following:

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


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

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


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

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:

What am I doing wrong?


Comment by Gradle Forums [ 20/Jun/13 ]

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


Comment by Doug Lethin [ 26/Sep/13 ]

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.

Comment by Dan Roden [ 29/Jan/14 ]

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

Comment by Tom Dunstan [ 02/May/14 ]

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.

Comment by andreas [ 19/May/14 ]

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

@Dan, did you find a workaround?

Comment by Sean Fitts [ 19/May/14 ]

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

Comment by Holger Stolzenberg [ 20/Feb/15 ]

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!

Comment by Flavio Baronti [ 26/Feb/15 ]

+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.

Comment by Jakob Englisch [ 08/May/15 ]

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

Comment by Jayson Minard [ 02/Aug/15 ]

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.

Comment by Bjarne Boström [ 13/Aug/15 ]

+1, same use case

Comment by Chris [ 12/Nov/15 ]

big issue

Comment by Marco Ehrentreich [ 21/Oct/16 ]


Comment by Joachim Nilsson [ 25/Oct/16 ]

I am surprised this is still not planned.

Comment by Benjamin Muschko [ 15/Nov/16 ]

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!

Comment by T K [ 08/Dec/16 ]

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.

Comment by Eric Wendelin [ 03/Feb/17 ]

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.

Comment by Eric Wendelin [ 03/Feb/17 ]

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

{ ... }


Generated at Wed Jun 30 12:31:54 CDT 2021 using Jira 8.4.2#804003-sha1:d21414fc212e3af190e92c2d2ac41299b89402cf.