With multiple repositories defined, is it possible to stop resolving on first match when using dynamic dependencies?

Old Forum
1

gradle: 1.0-rc-3 given the following build.gradle file:

repositories {
    maven {url "http://nexus.mycompany.com:8001/nexus/content/repositories/a/"}
    maven {url "http://nexus.mycompany.com:8001/nexus/content/repositories/b/"}
}
configurations {
 compile {transitive = false}
}
dependencies {
 compile 'a.group:themodule:5.3.1.+'
}

and given that we have version 5.3.1.100 in repository A and version 5.3.1.200 in repository B. Gradle resolves version 5.3.1.200 from repository B.

Is it possible to configure this in such a way that it will resolve version 5.3.1.100 from repository A (because repository A is first in line)?

2

Can you give a little more detail about why you want to do this?

3

Sure.

Scenario:

A developer is working on a project A which depends on project B. He then finds out that he needs to add an interface in project B to support the new feature in project A. Artifacts from project B are already in the remote repository being used, lets say version 5.3.1.100. Developer A checks out this version and starts working on it. In the meantime another developer B changes project B and uploads to remote repository. Now version 5.3.1.200 is the most recent version in repo. When developer A changes and uploads locally project B (uploaded as version 5.3.1.100) gradle does not resolve this version but the one that developer B uploaded to remote repo, since it has a higher version number.

I know it is not the nicest way to go about handling development versions but it is as it is at the moment and I need to support this. I can do some versioning meddling to get around this problem, but first I like to know if there would be a built in way I could use. The artifact resolving was working like this earlier (before 1.0-milestone-3 if I remember correctly) - i.e. order of repositories was significant.

4

I can assume then this is not possible?

5

The only way I can think of doing this is to use a task to tweak your cache timeout for dynamic versions. So you could have the default behaviour to use a long timeout for caching dynamic versions, and use ‘–refresh-dependencies’ to signal that Gradle should check for newer dynamic versions.

That would mean that once you were using 5.3.1.100 you’d keep using it until you ran with ‘–refresh-dependencies’. Alternatively you could use a command line property or task to set the dynamic version cache timeout to zero when you wanted to get a newer version.

// Set the cache timeout to a long time by default
configurations.all {
    resolutionStrategy.cacheChangingModulesFor 10, 'days'
}
  if (project.hasProperty('doNotCacheDynamicVersions')) {
    configurations.all {
        resolutionStrategy. cacheDynamicVersionsFor 0, 'seconds'
    }
}

We want to support use cases like yours in the future, but we’ll probably do it by modelling the development process more thoroughly rather than allowing you to tweak dependency resolution in the way you requested.

6

I don’t think that solution will help me enough with the problem at hand. If there was a way to hook into the resolution mechanism in such a way that you get which repository an artifact belongs to it would be simple for me to solve this. I know the repositories I’m interested in and which one I would choose (at least I could identify this scenario and alert the user on it).

Can’t wait for your solutions on this in the future and thanks a lot for all your effort.

Gradle rocks.