Strange behavior of BOM handling

[sebek64]

I'm seeing a strange behavior of the new BOM feature, where the dependency version is not resolved, but provided by the BOM.

Expected Behavior

Both configurations should work.

Current Behavior

The first configuration works, the second doesn't.

Context

I'm trying to upgrade BOM to newer version.

Steps to Reproduce (for bugs)

Create an empty project with enableFeaturePreview('IMPROVED_POM_SUPPORT'). Create a build script:

apply plugin: 'java'

repositories {
        mavenCentral()
}

dependencies {
        annotationProcessor group: 'org.wildfly.bom', name: 'wildfly-javaee7', version: '10.1.0.Final'
        annotationProcessor group: 'org.hibernate', name: 'hibernate-jpamodelgen'
}

gradle dependencies shows all dependencies to be resolved. Then, replace the first dependency with

        annotationProcessor group: 'org.wildfly.bom', name: 'wildfly', version: '12.0.0.Final'

Now, hibernate-jpamodelgen is not resolved. Both pom.xmls are very similar:

http://central.maven.org/maven2/org/wildfly/bom/wildfly-javaee7/10.1.0.Final/wildfly-javaee7-10.1.0.Final.pom
http://central.maven.org/maven2/org/wildfly/bom/wildfly/12.0.0.Final/wildfly-12.0.0.Final.pom

Your Environment

Gradle 4.6 (wrapper), openjdk 8, linux.

• Build scan URL:
  https://gradle.com/s/45n47rrniq4k2
  https://gradle.com/s/43sarrjttitze

[blindpirate]

@gradle/dependency-management can anyone take a look at this?

[melix]

The difference is that he second BOM has <scope>provided</scope> for jpamodelgen. We'd have to figure out what it actually means when the scope is provided in this case. Let me come back to you.

[melix]

Thanks for reporting this. TL/DR: we're going to ignore the scope of dependency management blocks when using BOMs.

So here is what happens. When a library author uses:

<dependencyManagement>
    <groupId>com.acme</groupId>
    <artifactId>foo</artifactId>
    <version>1.0</version>
    <scope>test</scope>
</dependencyManagement>

It's actually not specified in Maven what this means. However, when you see a scope in such a block, most likely the dependency management block was an implementation detail of the component, not supposed to be published as a BOM. So, when a dependency in the same POM is added:

<dependencies>
    <groupId>com.acme</groupId>
    <artifactId>foo</artifactId>
</dependencies>

then it's added with scope test, because of the dependency management block. Basically Maven works by "dependency first, then override the scope", where Gradle works on "scope first, dependency later". However, what does it mean when an external module depends on this dependency management block? Basically nothing. A consumer doesn't care that the scope was supposed to be test for the library itself, what it cares is to get a version, so we should just ignore the scope.

Under the hood, this is a modeling problem: at the same coordinates, live 2 different components. One is the library, for which, when it's built, the scope matters (but only when it is itself built), and the platform, for which the scope doesn't have any meaning, because all we want is suggestions. So by ignoring the scope when importing BOMs, we will effectively make it work the way you expect it to.

[sebek64]

Thank you for good news. I'm actually seeing some strange behavior on other places in the BOM handling, which are more complicated (I guess). It might be fixed by this change, so I'm awaiting a nightly build that contains this change, to test it on our project to see if everything is fixed.

[sebek64]

I've tried current master with the test project, and the behavior is the same - jpamodelgen dependency is not resolved:

https://scans.gradle.com/s/vl4rxus2h2dpu/

[jjohannes]

My bad. This is a caching issue I missed: the scope of the dependency management entries is cached. We need to invalidate the metadata in the dependencies cache.

Thank you very much for testing @sebek64. The fix is on master. Feel free to try again.

[sebek64]

Yes, now it's working fine.

Thank you very much for quick resolution of this issue.