Incorrect module version in descriptor when combining dynamic version + POM-less module

Old Forum Archive
1

For my example, I have 2 artifacts that I depend on for compile and I am using gradle 1.5. Both artifacts are stored in our Artifactory server but only artifactA has a POM, artifactB does not.

build.gradle

dependencies {
    compile(group: 'com.test', name: 'artifactA', version: '3.18.2.+')
    compile(group: 'com.test', name: 'artifactB', version: '3.18.2.+')
}
  task dumpResolved << {
    def arts = project.configurations.compile.resolvedConfiguration.resolvedArtifacts
    arts.each { println "${it.moduleVersion.id.group}, ${it.moduleVersion.id.module.name}, ${it.moduleVersion.id.version}" }
}

Now, when I display dependencies, only the artifact with the POM, artifactA, displays the resolved version number:

$ ./gradlew dependencies
compile - Classpath for compiling the main sources.
+--- com.test:artifactA:3.18.2.+ -> 3.18.2.0.999
\--- com.test:artifactB:3.18.2.+

Similarly, my dumpResolved task only shows the fully resolved version number for artifactA:

$ ./gradlew dumpResolved
:dumpResolved
com.test, artifactA, 3.18.2.0.999
com.test, artifactB, 3.18.2.+

Why the difference in behaviour? Is there a way to make my dumpResolved task work without POMs?

2

I should add that when I run a build, both dependencies are resolved as I expect:

$ ./gradlew build
:compileJava
Download http://artifactory:8081/artifactory/test-local/com/test/artifactA/3.18.2.0.999/artifactA-3.18.2.0.999.jar
Download http://artifactory:8081/artifactory/test-local/com/test/artifactB/3.18.2.0.130/artifactB-3.18.2.0.130.jar
:processResources UP-TO-DATE
:classes
:jar
:assemble
:compileTestJava UP-TO-DATE
:processTestResources UP-TO-DATE
:testClasses UP-TO-DATE
:test
:check
:build
  BUILD SUCCESSFUL
3

Hi Chris This looks like a bug in the way we generate a module descriptor when a dynamic version is used and no module metadata file is found. I’ll raise it in Jira. Thanks for reporting Daz

4

If you’re interested in taking a look at fixing this, I think I’ve isolated the issue. It looks like we should be using ‘descriptor.getResolvedModuleRevisionId()’ instead of ‘descriptor.getModuleRevisionId()’ here.

If that works it would be a pretty trivial fix, but some integration test coverage for this issue would be good (as well as checking that the build continues to work!).

A few more pointers: Test for resolution with metadata-less repository Code that locates jar file and builds module descriptor

5

Thanks for the pointers Daz, I will give it a go.