Dependency resolution scenarios


(Dan Stine) #1

I have two cases in which I’d like to change the dependency resolution logic. I don’t know if these are supported by the DSL or if I should be writing some custom code.

We are using dynamic versions (1.0.+) to specify some of our dependencies.

Case 1: For some dependencies I would like to include snapshot builds, but not for other dependencies.

compile 'com.mycompany:projecta:1.0.+'
// use 1.0.*-SNAPSHOT if it exists
compile 'com.mycompany:projectb:1.0.+'
// do not use 1.0.*-SNAPSHOT even if it exists

Snapshot and release builds are in different repositories, but both need to be included since I need artifacts out of both.

Is there DSL syntax I can use to do change the logic? Do I need to write a custom resolver (how do I do that)?

Case 2: We have introduced a custom type of build which includes the suffix LOCAL in the version number. So in addition to resolving amongst 1.0.10 and 1.0.10-SNAPSHOT we have 1.0.10-LOCAL. How can I specify that, for example, LOCAL takes precedence over SNAPSHOT?

Related query: pointers to the exact Gradle classes which perform dependency resolution would be appreciated.


#2

Currently, this logic is not customisable in any meaningful way.

The only way to get full control over dependency resolution is to implement an Ivy DependencyResolver yourself. Gradle still supports custom DependencyResolver implementations, but our intention is to remove this support at some point in the future (when we provide native DSL/extension support for the sort of use cases your presenting).

For Case 1, you may be able to solve this using a repository manager like Artifactory, with different virtual repositories that present the set of versions that should be available. I haven’t tried this, but I imagine that it’s possible.

For Case 2, a custom DependencyResolver is probably your best bet.

To find the source code for the Gradle dependency resolution engine, look under https://github.com/gradle/gradle/tree/master/subprojects/core-impl/src/main/groovy/org/gradle/api/internal


(Dan Stine) #3

Thanks for the info. I will digest this.