spring-boot plugin conflict

[ThomasGilbert]

Hi,

I'm trying to use this plugin along with the spring-boot one. There seem to be a conflict as this plugin does not load the dependencies from the .lock file as soon as I apply the spring-boot one. Maybe the problem comes from a spring-boot issue, but I wanted to report to you as well.

buildscript {
    repositories {
        mavenCentral();
    }
    dependencies {
        classpath 'org.springframework.boot:spring-boot-gradle-plugin:1.3.0.RELEASE'
        classpath 'com.netflix.nebula:gradle-dependency-lock-plugin:4.2.0'
    }
}

plugins {
    id "java"
    id 'nebula.dependency-lock' version '4.2.0'
}
apply plugin: 'spring-boot'

jar.baseName = 'foo'

repositories {
    mavenLocal()
    mavenCentral();
}

jar {
   doLast {
        println '------------ Dependencies ------------'
        configurations.compile.resolvedConfiguration.resolvedArtifacts.each { println it.file.name };
        println '--------------------------------------'
    }
}

dependencies {
    compile     ('com.hazelcast:hazelcast:3.6-RC1')
    compile     ('com.hazelcast:hazelcast-spring:3.6-RC1')
    compile     ('org.mariadb.jdbc:mariadb-java-client:1.1.7')
    compile     ('org.flywaydb:flyway-core')

    testCompile ('org.springframework.boot:spring-boot-starter-test')
}

task wrapper(type: Wrapper) {
    gradleVersion = '2.9'
}

In this example, as soon as you remove the spring-boot plugin and task, it's working as expected.

[nadavc]

Hi Thomas,

I might be misunderstanding the issue, but I wasn't able to reproduce the problem you're describing. Would appreciate if you could take the code I used and clarify what didn't work.

The code is on: https://github.com/nadavc/dl-86.git (run ./gradlew clean generateLock saveLock build)

[ThomasGilbert]

Hi,

Thank you very much for your feed-back!
First, not sure why, but I had to add a “:+” and the end of the unversioned dependencies to make it work ☺.

Any way, here’s the test case based on our useful example.

1- run ./gradlew clean generateLock saveLock build

2- the lock file is generated and correct

3- run ./gradlew clean build

4- the build is still OK

5- change the gradle dependencies to use another version of hazelcast, for example:
compile ('com.hazelcast:hazelcast:3.6-EA2')

6- run ./gradlew clean build

7- gradle is using the EA2 version and not the RC1 which is still in the lock file!

8- Remove the “apply plugin: spring-boot” line in the gradle script

9- run ./gradlew clean build

10- Now gradle is correctly using the RC1 from the lock file, though another dependency is mentioned in the script, as expected.

Hoping it helps!

Thomas

[ThomasGilbert]

Any update about this issue ?
Thanks !

[dholbrook]

I think this is related to spring-gradle-plugins/dependency-management-plugin#77

[wilkinsona]

I saw the reference to this issue on spring-gradle-plugins/dependency-management-plugin#77. I don't think this issue is related, but the behaviour you're seeing is due to the dependency management plugin that Spring Boot's plugin uses.

The goal of the dependency management plugin is to control the versions of a project's dependencies (both direct and transitive). In the configuration in the example at the top of this issue, it's using Spring Boot's bom as a source of versions. That's what allows the org.flywaydb:flyway-core and org.springframework.boot:spring-boot-starter-test dependencies to be specified without a version. When you do specify a version of a dependency, the dependency management plugin "adopts" that version and ensures that any direct and transitive references to the same dependency also use that version. It's this behaviour that is clashing with this plugin.

You've specified a dependency on com.hazelcast:hazelcast:3.6-EA2 so the dependency management plugin tries to ensure that version 3.6-EA2 is used. This plugin and the dependency management plugin have competing goals and the dependency management plugin is winning. It appears to be winning due to using resolutionStrategy.eachDependency to configure the versions vs resolutionStrategy.force. Unfortunately, the ResolutionStrategy API is write-only – there's no API to get the forced modules – so the dependency management plugin can't skip them when it's applying its configuration.

Unfortunately, this means that I'm not sure that there's an easy way to fix this problem. Irrespective of how they're implemented the two plugins are always going to have compete with each other. The best solution may be to stop using one of the plugins.

[DanielThomas]

It appears to be winning due to using resolutionStrategy.eachDependency to configure the versions vs resolutionStrategy.force

Exactly right - eachDependency wins over a force. We jump through some hoops to make sure that dependency locks are applied as late as possible, so we win; we need to switch to eachDependency too.

@rspieldenner we'll probably see issues with align resolution rules too. Think we'll need to do something about this sooner rather than later.

[DanielThomas]

Technically a dupe of #76, but I'll keep this open because there's a bunch of useful context here, and we'll want functional tests that specifically verify locking with Spring's dependency management plugin.

[DanielThomas]

@ThomasGilbert @dholbrook @wilkinsona release 4.3.0 is on it's way out now. You'll find it should co-exist far better with other plugins now:

• Locks are applied inside a incoming.beforeResolve, ensuring that locks are applied per-configuration, and at the last possible moment
• We use eachDependency.useTarget, which wins over force and due to the beforeResolve change should win over any other useTarget or useVersion call

[DanielThomas]

Oh, and we appreciate the report - this feedback allowed us to make the plugin immensely more reliable and predictable.