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

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…

Example

Repository set to http://repo.spring.io/plugins-release/org/springframework/data/spring-data-mongodb/ Dependency is: compile group: ‘org.springframework.data’, name: ‘spring-data-mongodb’, version: ‘1.5.+’

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

<?xml version="1.0" encoding="UTF-8"?>
<metadata>
  <groupId>org.springframework.data</groupId>
  <artifactId>spring-data-mongodb</artifactId>
  <version>1.0.1.RELEASE</version>
  <versioning>
    <latest>1.5.0.RELEASE</latest>
    <release>1.5.0.RELEASE</release>
    <versions>
    .....
  </versioning>
</metadata>

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

1.5.0.M1/

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.

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.

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.