The order of declaring dependencies determines the resolution outcome


(Szczepan Faber) #1

I wasn’t sure how to title this problem. I also didn’t find the corresponding jira ticket. I’d like to document this behavior here.

Given that we use the default resolution strategy (‘Newest’), reordering the dependencies declarations might lead to different resolution results (e.g. failure or success). It happens when incorrectly configured (not existing version) direct dependency has been already resolved as a transitive dependency. Our algorithm will not attempt to resolve the dependency again regardless if the version was correct or not. To be more precise, our algorithm might try resolving the dependency if the version encountered is higher than the one already resolved.

I tried few versions and the behavior is the same for M3,M5,M6. It feels somewhat undesired that the declaration order may affect the resolution outcome. It might be confusing. If we want to fix it we also should consider doing it in a non-breaking way for the users.

apply plugin: ‘java’

repositories {

mavenCentral() }

dependencies {

//comment/uncomment the pairs to expose

//

//works (annotations resolved transitively earlier):

//compile “org.hibernate:hibernate-entitymanager:3.5.0-Final”

//compile “org.hibernate:hibernate-commons-annotations:i-dont-exist”

//

//doesn’t work:

//compile “org.hibernate:hibernate-commons-annotations:i-dont-exist”

//compile “org.hibernate:hibernate-entitymanager:3.5.0-Final”

//

//works (because 0.5 is considered older):

//compile “org.hibernate:hibernate-entitymanager:3.5.0-Final”

//compile “org.hibernate:hibernate-commons-annotations:0.5-i-dont-exist”

//

//doesn’t work (newer version is attempted to resolve):

//compile “org.hibernate:hibernate-entitymanager:3.5.0-Final”

//compile “org.hibernate:hibernate-commons-annotations:100-i-dont-exist” }

task wrapper(type:Wrapper) {

gradleVersion = ‘1.0-milestone-6’ }