Dependency resolving fails for certain maven artifacts

Details

Type: Bug
Status: Resolved
Resolution: Fixed
Affects Version/s: None
Fix Version/s: 1.0-milestone-4

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

Activity

Ascending order - Click to sort in descending order

Hide

Permalink

Hans Dockter added a comment - 25/Jun/10 4:22 AM

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.

Show

Hans Dockter added a comment - 25/Jun/10 4:22 AM 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:

Hide

Permalink

Zsolt Kúti added a comment - 25/Jun/10 4:41 AM

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!

Show

Zsolt Kúti added a comment - 25/Jun/10 4:41 AM 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!

Hide

Permalink

Hans Dockter added a comment - 25/Jun/10 4:52 AM

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.

Show

Hans Dockter added a comment - 25/Jun/10 4:52 AM 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.

Hide

Permalink

Pivotal Tracker Integration added a comment - 04/Aug/11 5:33 PM

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

Show

Pivotal Tracker Integration added a comment - 04/Aug/11 5:33 PM A Pivotal Tracker story has been created for this Issue: http://www.pivotaltracker.com/story/show/16643573

Hide

Permalink

Pivotal Tracker Integration added a comment - 04/Aug/11 5:34 PM

Daz DeBoer deleted the linked story in Pivotal Tracker

Show

Pivotal Tracker Integration added a comment - 04/Aug/11 5:34 PM Daz DeBoer deleted the linked story in Pivotal Tracker

Hide

Permalink

Luke Daley added a comment - 21/Aug/11 8:25 AM

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

Show

Luke Daley added a comment - 21/Aug/11 8:25 AM This has been fixed by the new dependency resolver implementation. This invalid dependency relationship is silently ignored, just like Maven.

People

Assignee:

Luke Daley

Reporter:

Zsolt Kúti

Vote (0)

Watch (0)

Dates

Created:

23/Jun/10 11:29 AM

Updated:

04/Jan/13 5:09 AM

Resolved:

21/Aug/11 8:25 AM