[GRADLE-2083] http status code 403 stops ivy resolver? Created: 06/Feb/12  Updated: 10/Feb/17  Resolved: 10/Feb/17

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

Type: Improvement
Reporter: Gradle Forums Assignee: Unassigned
Resolution: Won't Fix Votes: 3


I am trying to add a build dependency on a url to a jar along the lines of the suggestions in given by Daz DeBoer in the forums here: [1]http://gsfn.us/t/2m4hp

I think I have it working in one case, but another jar on githup doesn't work. What I think is happening is the the Ivy resolver first tries to get the .ivy file, which doesn't exist. But, because the github server returns a "403 Forbidden" instead of a 404, it gives up, even though if it just went ahead and tried to get the jar using the same pattern, it would succeed. To see this, replace ".xml" with ".jar" and the download works.

Is this an ivy or gradle bug? Should I be doing something different so that the lack of the .ivy file does not cause a build failure?

This is with Gradle 1.0-milestone-7.

Here is the build.gradle, using the izpack plugin as a test case:

buildscript {
repositories {
ivy {
artifactPattern 'http://cloud.github.com/downloads/[organisation]/[module]/[module]-[revision].[ext]'

dependencies {
classpath 'bmuschko:gradle-izpack-plugin:0.1'

And the output:

FAILURE: Build failed with an exception.

  • What went wrong:
    Could not resolve group:bmuschko, module:gradle-izpack-plugin, version:0.1.
    Required by:
    Cause: Could not GET 'http://cloud.github.com/downloads/bmuschko/gradle-izpack-plugin/gradle-izpack-plugin-0.1.xml'. Received status code 403 from server: Forbidden
  • Try:
    Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output.


Here is another example for a different jar, also where the corresponding .ivy file does not exist:

buildscript {
repositories {
ivy {
artifactPattern 'http://gradle-macappbundle.googlecode.com/files/[module]-[revision].[ext]'

dependencies {
classpath 'edu.sc.seis:gradle-macappbundle:1.0.1'

and the output:

Download http://gradle-macappbundle.googlecode.com/files/gradle-macappbundle-1.0.1.jar

Welcome to Gradle 1.0-milestone-7.

To run a build, run gradle <task> ...

To see a list of available tasks, run gradle tasks

To see a list of command-line options, run gradle --help


[1] http://gsfn.us/t/2m4hp

Comment by Christian K [ 14/Mar/13 ]

This should fix it - gradle should not care if there is an exception during fetching the ivy xml.

--- a/subprojects/core-impl/src/main/groovy/org/gradle/api/internal/artifacts/repositories/resolver/ExternalResourceResolver.java
+++ b/subprojects/core-impl/src/main/groovy/org/gradle/api/internal/artifacts/repositories/resolver/ExternalResourceResolver.java
@@ -288,7 +288,16 @@ public class ExternalResourceResolver implements DependencyResolver {
     public ResolvedResource findIvyFileRef(DependencyDescriptor dd) {
         ModuleRevisionId mrid = dd.getDependencyRevisionId();
         Artifact artifact = DefaultArtifact.newIvyArtifact(mrid, null);
-        return findResourceUsingPatterns(mrid, ivyPatterns, artifact, getRMDParser(dd), null, true);
+        try {
+            return findResourceUsingPatterns(mrid, ivyPatterns, artifact, getRMDParser(dd), null, true);
+        } catch (RuntimeException e) {
+            if(e.getCause() instanceof IOException) {
+                return null;
+            } else {
+                throw e;
+            }
+        }

     protected ResolvedResource findFirstArtifactRef(ModuleDescriptor md) {

I worked around the issue by setting ivyPattern to some url that returns a 404

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 Benjamin Muschko [ 10/Feb/17 ]

Thanks again for reporting this issue. We haven't heard back from you after our inquiry from November 15th. We are closing this issue now. Please create an issue on GitHub if you still feel passionate about getting it resolved.

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