Overlapping pom dependency management entries can cause a wrong dependency scope in Gradle 4.5

[wreulicke]

Expected Behavior

I added dependency of "org.zalando:logbook-spring-boot-starter:1.5.3" into my module.
slf4j-simple and lombok is not resloved as dependencies of "logbook-spring-boot-starter" .

I seems to have no that dependency in the module

Current Behavior

In gradle 4.5, just resolved as dependencies.
But in gradle 4.4, not resolved.

Context

Steps to Reproduce (for bugs)

Next gradle task shows change of dependencies between gradle 4.4 and 4.5.

gradle dependencies

Your Environment

• Build scan URL: private repository. (try to reproduce other public repository)

[wreulicke]

Related? #4171

[jjohannes]

@wreulicke thanks for reporting. I can reproduce this. It is a regression.

Looks like json-path-assert:2.2.0 is somehow promoted to the compile scope although it is defined in test scope in the parent POM.

[jjohannes]

Actually the pom org.zalando.logbook-parent:logbook-parent linked above imports org.springframework.boot:spring-boot-dependencies. Which also has an entry for json-path-assert - without scope.

We treat entries with different scopes now separately. Before, one entry would just override the other. Which could lead to information loss, if we have two entries with different scopes. See: a82cf4a

I think the issue now is that we treat the entry without scope as "scope == compile", independent of whether we saw other entries or not. But we should only do that if no scope is defined at all in any entry.

[jjohannes]

After investigating further, I think the change (a82cf4a) was a mistake. Even if we fix the case here, there are other cases where we would need to "merge" information from multiple dependency management entries to have the "correct" (i.e. mavens) behaviour. But that would mean that the behaviour changes for some cases.

If we do this more involved change (I'll open a separate issue for it), then we should do it for 5.0.

For now, I will revert a82cf4a for 4.6.

@wreulicke is this actually blocking you from using 4.5 or is it something you "just noticed"? Can you work around it with an exclude?

[wreulicke]

@jjohannes thanks for your comments.

@wreulicke is this actually blocking you from using 4.5 or is it something you "just noticed"? Can you work around it with an exclude?

blocking. But I can work around for few part.

In my case, my runtime dependencies was contaminated due to this issue.
So, this contamination leads to break a application because there are two slf4j implementation in my classpath (ex. logback and slf4j-simple).

In above case, I can work around. Following.

configurations.all {
  exclude module: 'slf4j-simple'
}

My runtime dependencies was contaminated by other dependency lombok, yet.
lombok may be harmless in runtime.
But there are no solution to this contaimination...

Do you have any solution?

[jjohannes]

To clarify: The issue can only appears if one of the poms defines a dependency without scope and where a scope is added via <dependencyManagement/>. And where another <dependencyManagement/> entry exists with a different scope.

The revert of the change above will bring us back to what we had prior to 4.5:
We always pick the "closest" dependency management entry - which is the one with test scope in your setting - and ignore all the other entries.

But it looks like it's worse for you than I thought. There are multiple test dependencies following this pattern - including lombock as you noticed.
You can work around this by using one of our experimental new APIs for component metadata rules. These allow you to adjust the metadata and remove the dependencies. Here is a script that should remove all the wrong entries:

dependencies {
    components {
        all { metadata ->
            workaroundGradle4202(metadata, "com.jayway.jsonpath", "")
            workaroundGradle4202(metadata, "org.projectlombok", "")
            workaroundGradle4202(metadata, "org.mockito", "")
            workaroundGradle4202(metadata, "org.springframework", "spring-test")
            workaroundGradle4202(metadata, "org.slf4j", "jcl-over-slf4j")
            workaroundGradle4202(metadata, "org.slf4j", "slf4j-nop")
            workaroundGradle4202(metadata, "org.slf4j", "slf4j-simple")
        }
    }
}

def workaroundGradle4202(ComponentMetadataDetails metadata, String testDependencyGroup, String testDependencyName) {
    metadata.withVariant("default") {
        withDependencies { it.removeAll {
            it.group == testDependencyGroup && (testDependencyName.empty || it.name == testDependencyName)
        }}
    }
    metadata.withVariant("runtime") {
        withDependencies { it.removeAll {
            it.group == testDependencyGroup && (testDependencyName.empty || it.name == testDependencyName)
        }}
    }
}

Note that this API is not yet finished and officially released and will change in future versions. But this way it works for 4.5 as workaround.

Excluding all the dependencies as you started to do probably also work if you exclude all the ones listed above.

[jjohannes]

We have a 4.5.1 release scheduled for Monday that will include a fix for this.

PR with fix (revert): #4244

[wreulicke]

We have a 4.5.1 release scheduled for Monday that will include a fix for this.

@jjohannes thanks to your quickly support. 👍