[GRADLE-1005] Dependency resolving fails for certain maven artifacts Created: 23/Jun/10  Updated: 04/Jan/13  Resolved: 21/Aug/11

Status: Resolved
Project: Gradle
Affects Version/s: None
Fix Version/s: 1.0-milestone-4

Type: Bug
Reporter: Zsolt Kúti Assignee: Luke Daley
Resolution: Fixed Votes: 0


 Description   

When I try to use a dependency the following error appears:

:::: ERRORS
a module is not authorized to depend on itself: net.jini#jsk-platform;2.1

FAILURE: Build failed with an exception.

  • What went wrong:
    Could not resolve all dependencies for configuration ':compile'.
    Cause: java.lang.IllegalArgumentException: a module is not authorized to depend on itself: net.jini#jsk-platform;2.1
  • Exception is:
    org.gradle.api.artifacts.LocationAwareResolveException: Could not resolve all dependencies for configuration ':compile'.
    at org.gradle.api.internal.artifacts.ivyservice.ErrorHandlingIvyService.wrapException(ErrorHandlingIvyService.java:63)
    at org.gradle.api.internal.artifacts.ivyservice.ErrorHandlingIvyService.access$000(ErrorHandlingIvyService.java:28)
    at org.gradle.api.internal.artifacts.ivyservice.ErrorHandlingIvyService$BrokenResolvedConfiguration.rethrowFailure(ErrorHandlingIvyService.java:127)
    ....
    Caused by: java.lang.IllegalArgumentException: a module is not authorized to depend on itself: net.jini#jsk-platform;2.1
    at org.apache.ivy.core.resolve.IvyNodeCallers.addCaller(IvyNodeCallers.java:169)
    at org.apache.ivy.core.resolve.IvyNode.addCaller(IvyNode.java:1026)
    at org.apache.ivy.core.resolve.IvyNode.getDependencies(IvyNode.java:352)
    at org.apache.ivy.core.resolve.VisitNode.getDependencies(VisitNode.java:301)
    at org.apache.ivy.core.resolve.ResolveEngine.doFetchDependencies(ResolveEngine.java:750)
    at org.apache.ivy.core.resolve.ResolveEngine.fetchDependencies(ResolveEngine.java:679)
    at org.apache.ivy.core.resolve.ResolveEngine.doFetchDependencies(ResolveEngine.java:757)
    at org.apache.ivy.core.resolve.ResolveEngine.fetchDependencies(ResolveEngine.java:679)
    at org.apache.ivy.core.resolve.ResolveEngine.doFetchDependencies(ResolveEngine.java:757)
    ....

A bare-bone script that shows this:

repositories {
mavenRepo urls: 'http://www.rio-project.org/maven2/'
}

dependencies {
compile group: 'org.rioproject', name: 'rio', version: '4.0'
}

Although there is an Ivy issue which seems to have the same root:
https://issues.apache.org/jira/browse/IVY-1086
I decided to report it here, because that report is rather old and at least a workaround would be needed for gradle as soon as it is possible.
I do not know how to solve this problem. Until I am not able to use this repo, can not get rid of my custom repo and change fully to a repo manager (like artifactory, where the issue also appears).
.

 Comments   
Comment by Hans Dockter [ 25/Jun/10 ]

The failing dependency has the following pom:

<project> 
  <modelVersion>4.0.0</modelVersion> 
  <groupId>net.jini</groupId> 
  <artifactId>jsk-platform</artifactId> 
  <name>Jini Starter Kit Platform Jar</name> 
  <version>2.1</version> 
  <inceptionYear>2005</inceptionYear> 
  <organization /> 
  <build /> 
  <dependencies> 
    <dependency> 
      <groupId>net.jini</groupId> 
      <artifactId>jsk-platform</artifactId> 
      <version>2.1</version> 
    </dependency> 
  </dependencies> 
</project>

You could argue that such a pom does not make any sense. On the other hand Maven resolves is without throwing an exception. If you look at the Maven resolve debug output you find the following:

[INFO] skip non existing resourceDirectory /Users/hans/tmp/maven/recu/src/main/resources
[DEBUG] gradle:recu:jar:1.0-SNAPSHOT (selected for null)
[DEBUG]   junit:junit:jar:3.8.1:test (selected for test)
[DEBUG]   net.jini:jsk-platform:jar:2.1:compile (selected for compile)
[DEBUG]     net.jini:jsk-platform:jar:2.1:compile (removed - causes a cycle in the graph)
[DEBUG] Plugin dependencies for:

The problem is that Ivy's approach for Maven compatibility is reverse engineering Maven's behavior. Whether the above pom makes sense or not is a mute point. We need to provide the same behavior as Maven. To achieve that we will use a native Maven resolver in Gradle 1.0, where we use embedded Maven to let Maven do the job without the need for reverse engineering it's behavior.

Comment by Zsolt Kúti [ 25/Jun/10 ]

So my short term options to get around this are:

  • a pom that avoids this "cycle in the graph"
  • an Ivy solution (that can get into gradle) to mimic maven behaviour (doubt whether it's really short term)
  • asking automatic pom rewrite, if possible, from artifactory (they already do such for other maven problems)

Thanks for looking into it!

Comment by Hans Dockter [ 25/Jun/10 ]

Right. The Ivy solution is probably not short term. What we are planning for 1.0 is to provide an Ivy resolver that uses native maven code for resolving pom's. The default Ivy Maven resolver parses the pom itself and tries to interpret it. That way you are bound to run into corner cases.

Comment by Pivotal Tracker Integration [ 04/Aug/11 ]

A Pivotal Tracker story has been created for this Issue: http://www.pivotaltracker.com/story/show/16643573

Comment by Pivotal Tracker Integration [ 04/Aug/11 ]

Daz DeBoer deleted the linked story in Pivotal Tracker

Comment by Luke Daley [ 21/Aug/11 ]

This has been fixed by the new dependency resolver implementation. This invalid dependency relationship is silently ignored, just like Maven.

Generated at Wed Jun 30 11:44:28 CDT 2021 using Jira 8.4.2#804003-sha1:d21414fc212e3af190e92c2d2ac41299b89402cf.