Force dependency to be resolved against a specific set of repository

Old Forum Archive
1

One thing I miss in all build tools, and Gradle is not an exception, is the ability to specify where each dependency can be found, on which repository. That could be a huge benefit for either performance and clarity reasons. Furthermore, I don’t think that it would be hard for Gradle to implement it. Let’s take an example from my own experience. I have 3 repositories : R1,R2 and R3 and 4 dependencies D1, D2, D3, D4. D3 and D4 are some uncommon librairies which can be found only on R2 and R3 respectively. Of course R2 and R3 are both really slow. Due to the gradle architecture when D4 is resolved, it has to check both R2 and R3 => slow and useless. Correct me if I am wrong but if, for example, D1 has a dynamic version (‘1.+’) all repositories will be check => slow and useless since we know that D1 can be found on R1 only.

I think a solution would be the ability to: 1) specify that a dependency can be found only on a set of repository 2) specify that a repository should not be checked for dependency resolution unless it has been explicitly associated with the dependency

Something like that :

repositories {
        maven { url:'XXX', name :'R1'}
        maven { url:'XXX', name :'R2'}
        maven { url:'XXX', name :'R3', implicit:false}
    }
    dependencies {
       runtime group: 'D1', name: 'D1', version: '1.+'
// will be resolved against all "non implicit" repos, here R1 and R2
       runtime group: 'D2', name: 'D2', version: '1.2'
       runtime group: 'D3', name: 'D3', version: '1.+', repos: ['R2'] // will be resolved against R2 only
       runtime group: 'D4', name: 'D4', version: '1.+', repos: ['R2','R3'] // will be resolved against R2 and R3 only
    }

Let me know what you think about it. That is personnally something I would love to have, not only for performance. Sometimes I am wondering why R3 has been added and if it is actually used. Here, it is obvious.

I would be glad to see if other people have the same need and if it it is the case I would be glad to implement it!

1 Like
2

Hi Delor,

This is something that we are aware of and looking to solve eventually. Dependency management in general is undergoing lots of internal restructuring in order to isolate and replace Ivy. We are avoiding making too many top level changes until we are further through this process.

That said, if you’re willing to help out that always helps bring things up the queue :slight_smile:

I’ll bring this thread to the attention of all the developers so we can discuss the feasibility.

1 Like
3

Can a JIRA be created to mirror this request? I also struggle with mixing dependencies with repositories. We’re force to deal with this because it’s common for plugins to create their own configuration and add their dependencies (e.g. findbugs plugin), which forces me to either mirror their dependencies in my internal repo or expose Maven Central for all dependencies. For our scenario, exposing Maven Central is a no-go, so we end up manually adding dependencies to our internal repo as plugins use them. Of course the don’t ever document these and I have to deal with all their transitive dependencies too. Just isolating configurations to certain repositories would solve the problem for me.

1 Like
4

It’s GRADLE-1066.

1 Like