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…

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.


(Alexej Kubarev) #2

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


#3

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


#5

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.