Difference between ResolvedConfiguration#getResolvedArtifacts and #getResolutionResult

Old Forum
1

Gradle 1.2 added the ResolutionResult api which gives you info about the dependency graph as a tree of nodes. There was an existing API that appeared to provide the same information which is getResolvedArtifacts which yields a set of ResolvedArtifact instances which also give you the same information.

What’s the difference between these?

The reason I ask is because I currently use this information to turn a dynamic dependency into a stable (specific) version when publishing a pom to our binary repo.

2

Thanks for asking - very good question. We should actually put this information in the API.

There are number of things we don’t like about the ResolvedConfiguration API. ResolvedConfiguration/ResolvedDependency types have some questionable methods in the API, ResolvedDependency isn’t really node in the dependency graph but rather a part of ivy resolved configurations graph, etc. ResolutionResult API will replace ResolvedConfiguration/ResolvedDependency API at some point. Don’t worry, though, it’s nothing that will happen fast - it will be a slow, backwards-compatible evolution. Right now, ResolutionResult API does not contain all the information that ResolvedConfiguration has. However, it does contain some extra stuff that should be really useful (information about the requested versions, the reason a version was selected, etc.). Also keep in mind that the new API is still @Incubating, it will change slightly before 1.3.

Your use case is very interesting. At some point we would probably want to have a higher level abstraction over exactly this use case.

Can you tell me if you could use the new API to acquire the information you need before publishing poms?

3

My use case is really just an ‘ivy:deliver’

The only obvious difference between the APIs is that the new api doesn’t allow selection by classifier where the old one does, e.g.

def matchesNew = conf.resolvedConfiguration.resolutionResult.root.dependencies.findAll {
     it.requested.group.equals(dep.groupId) && it.requested.name.equals(dep.artifactId)
  }
def matchesOld = conf.resolvedConfiguration.resolvedArtifacts.findAll {
    it.moduleVersion.id.group.equals(dep.groupId) && it.moduleVersion.id.name.equals(dep.artifactId) && (it.classifier == null || (it.classifier != null && it.classifier.equals(dep.classifier)))
}

dep is a Dependency from the MavenPom

4

On a side note, actually the use case is directly related to

http://issues.gradle.org/browse/GRADLE-1663 because we currently have the API to modify the pom before publication, but we can’t do this for the publication on an ivy repos for the ivy.xml (but it should be solved in Gradle 1.3 as per ‘Gradle 1.3 release outlook’ http://forums.gradle.org/gradle/topics/gradle_1_3_release_outlook)

5

Thanks. The new API will have a possibility to iterate/recurse artifacts at some point and it will support classifiers.

6

Right, we’re planning to help solving the ivy deliver use case in 1.3. As usual, the release outlook is not a fully accurate promise but rather our priority queue :slight_smile: