Pom.xml dependency ordering breaks Maven users

Help/Discuss
1

When releasing a project the order of dependencies in the generated pom.xml caused a transitive dependency to not be resolved for Maven users. This project dependency was included twice, as both compile and test scoped, and the latter was honored by Maven. The result is that a new release is required to be Maven compatible.

The problem is that the primary project uses a sibling project’s test artifact to reuse utility methods. This is done by doing,

dependencies {
  compile project(':tracing:api')
  testCompile project(path: ':tracing:api', configuration: 'testArtifacts')
}

The generated pom then becomes,

<dependencies>
  <dependency>
    <groupId>com.github.ben-manes.caffeine</groupId>
    <artifactId>tracing-api</artifactId>
    <version>1.3.0</version>
    <scope>compile</scope>
  </dependency>
  <dependency>
    <groupId>com.github.ben-manes.caffeine</groupId>
    <artifactId>tracing-api</artifactId>
    <version>1.3.0</version>
    <scope>test</scope>
  </dependency>
</dependencies>

This should work, but unfortunately Maven remembers the last dependency definition’s scope. This is probably a misuse of a HashMap of the coordinates and not handling duplicates. A mvn dependency:tree shows that the transitive dependency is not pulled in. If the pom is hacked and the order reversed, Maven correctly resolves the dependency.

This appears to be a bug in Maven and was easy enough to work around, but Gradle may need to be careful about the order of dependencies that it generates.