ResolvedArtifact returns incorrect extension for certain artifacts

[bjlaub]

Expected Behavior

Certain POMs on Maven Central (specifically, javax.ws.rs:javax.ws.rs-api:2.1.1) contain some unusual usages of variable substitution, where the <packaging> field is set to a property that is only defined when a specific profile is activated.

I would expect the following code:

dependencies {
    implementation 'javax.ws.rs:javax.ws.rs-api:2.1.1'
}
task foo {
    doLast {
        configurations.runtimeClasspath.resolvedConfiguration.resolvedArtifacts.each {
            println it.extension
        }
    }
}

to output

jar

(since the ResolvedArtifact for this dependency indeed is a jar).

Current Behavior

For the code snippet above, on Gradle 7.5+, the output is:

${packaging.type}

instead.

For Gradle 7.4.2, the output is:

jar

as expected.

Context

This particular POM is a little bit weird, and there is some past history with it (see #3065).

In our case, we have several internal repositories that use this pattern (for better or worse):

configurations.foo.resolvedConfiguration.resolvedArtifacts.collect { "${it.moduleVersion.id}@${it.extension}" }

and iterate over the resulting strings assuming they are Maven coordinates that are sent to another process to resolve dependencies from. In those cases, we expect the getExtension() method to return some "standard" extension that Maven likely understands, but instead the resolution fails since it is being told to look for a dependency with an extension of ${packaging.type}.

This pattern works as expected in Gradle 7.4.2, but the output changed in Gradle 7.5. It's possible this is not really a regression, and is actually a case of "we fixed a bug," but it's hard for me to tell without knowing more about the internals of Gradle.

Steps to Reproduce

The following integration test will reproduce the issue:

package org.gradle.api

import org.gradle.integtests.fixtures.AbstractIntegrationSpec
import static org.gradle.integtests.fixtures.RepoScriptBlockUtil.mavenCentralRepositoryDefinition

class ResolvedArtifactGetExtensionIntegrationTest extends AbstractIntegrationSpec {
    def "javax.ws.rs-api:2.1.1 produces correct extension on ResolvedArtifact"() {
        given:
        buildFile << """
            apply plugin: "java-library"

            ${mavenCentralRepository()}

            dependencies {
                implementation "javax.ws.rs:javax.ws.rs-api:2.1.1"
            }

            task wut {
                doLast {
                    configurations.runtimeClasspath.resolvedConfiguration.resolvedArtifacts.each {
                        println "\${it.moduleVersion.id}@\${it.extension}"
                    }
                }
            }
        """.stripIndent()

        when:
        run 'wut'

        then:
        result.assertNotOutput("\${packaging.type}")
    }
}

It passes on 7.4.2, and fails on 7.5+.

(I don't know how to construct a unit test to demonstrate this because I'm not exactly sure which unit is causing the problem)

Your Environment

I don't have a build scan, but the integration test above should easily reproduce the issue when run from the Gradle source tree in any environment. I tested specifically on MacOS 12.6.2 using JDK version:

openjdk version "11.0.15" 2022-04-19
OpenJDK Runtime Environment Homebrew (build 11.0.15+0)
OpenJDK 64-Bit Server VM Homebrew (build 11.0.15+0, mixed mode)

as the JVM that launched the Gradle wrapper.

[bjlaub]

on 7.4.2, resolving this artifact goes through this codepath: https://github.com/gradle/gradle/blob/v7.4.2/subprojects/dependency-management/src/main/java/org/gradle/api/internal/artifacts/repositories/resolver/MavenResolver.java#L255-L260. Evidently it first checked if an artifact with the bogus extension ${packaging.type} existed, and then would fall back to returning a ModuleComponentArtifactMetadata with the extension set to "jar" if not.

That code was deleted in 65eb04e.

[TheMrMilchmann]

FYI, I believe that this might also be the underlying cause for #21526.

[CRogers]

Just got wrecked by this too (context)

[CRogers]

This is also a problem in the configuration.getIncoming().getArtifacts().getResolvedArtifacts().get() api too - at least with the toString() method: javax.ws.rs-api-2.1.1.${packaging.type} (javax.ws.rs:javax.ws.rs-api:2.1.1)

[ov7a]

Sorry for the late reply.

Thank you for providing a valid report.

The issue is in the backlog of the relevant team, but this area of Gradle is currently not a focus one, so it might take a while before a fix is made.

[big-guy]

fixed in #26850