Maven dependency resolution ignores maven-metadata.xml and goes by Last Modified date

(Alexej Kubarev) #1

When Gradle tries to resolve a dependency with version containing “+” instead of taking the “latest” as specified by maven-matadata.xml, it seems to go by either “string comparison” on versions or modification date…


Repository set to Dependency is: compile group: ‘’, name: ‘spring-data-mongodb’, version: ‘1.5.+’

At the time of posting repository maven-metadata.xml contained:

<?xml version="1.0" encoding="UTF-8"?>

Repository artifacts (latest ones) with last modififed date were:


09-Apr-2014 08:04 1.5.0.RC1/

21-May-2014 21:46 1.5.0.RELEASE/

20-May-2014 16:38

Expected Result_ Dependency resolved to “1.5.0.RELEASE”

Actual Result Dependency resolves to “1.5.0.RC1”

When Gradle resolves dependencies it takes “1.5.0.RC1” over “1.5.0.RELEASE” which is defined in maven-metadata.xml. By looking at Last Modified date above it would seem that it goes by this date, over metadata definition.

(Alexej Kubarev) #2

Just wondering If this is actually an proper behavior as for me it does sound a bit backwards…


When resolving ‘‘1.5.+’’, Gradle is not taking the ‘maven-metadata.xml’ file into account. This is a limitation that I have raised as GRADLE-3119.

The reason for the strange ordering you’re seeing is that Gradle treats ‘RC’ and ‘FINAL’ as special values within a version, so that “1.0-anything” < “1.0-RC” < “1.0-FINAL”. Since ‘RELEASE’ is not a special value to Gradle, ‘1.5.0.RELEASE’ is considered less than ‘1.5.0.RC1’. This behaviour was inherited from Ivy and will be difficult to change without breaking backward compatibility.

(Alexej Kubarev) #4

I see, even though this is quite disturbing. So my observation about modification date is a simple coincidence?

It would make sense to at least treat maven-metadata.xml properly when handling Maven deps


Yes, I believe that it’s a coincidence that modification dates matched the version order.

It won’t be a trivial fix to start using maven-metadata.xml for listing versions. But if you’re interested in helping out with a solution, we can start a discussion on the gradle developers list.