Option for disabling dependency management

[masc3d]

I have just updated to spring-boot-gradle-plugin-1.3.0 and realized the dependency management plugin is now included transitively.

I have a multi project build with a gradle resolution strategy applied to all subprojects. spring-boot is only used in one of those subprojects and the dependency plugin will silently override any resolution strategies for packages it has in its own dependency configuration

I might have missed it, but I could not figure out a way to entirely disable it.

[wilkinsona]

I've done a little experimentation and I'm not sure that this is really necessary. If you configure your own resolution strategy after you've applied the Spring Boot plugin:

buildscript {
    repositories {
        mavenCentral()
        maven { url 'https://repo.spring.io/libs-snapshot' }
    }
    dependencies {
        classpath 'org.springframework.boot:spring-boot-gradle-plugin:1.3.0.BUILD-SNAPSHOT'
    }
}

apply plugin: 'spring-boot'

configurations.compile {
    resolutionStrategy.eachDependency { DependencyResolveDetails details ->
        if (details.requested.group == 'org.springframework') {
            details.useVersion '4.0.0.RELEASE'
        }
    }
}

repositories {
    mavenCentral()
    maven { url 'https://repo.spring.io/libs-snapshot' }
}

dependencies {
    compile 'org.springframework:spring-core'
}

It will take precedence over Boot's dependency management and will give you 4.0.0.RELEASE of spring-core:

gradle dependencies --configuration compile
:dependencies

------------------------------------------------------------
Root project
------------------------------------------------------------

compile - Compile classpath for source set 'main'.
\--- org.springframework:spring-core: -> 4.0.0.RELEASE

BUILD SUCCESSFUL

Total time: 6.983 secs

To have Spring Boot's dependency management take precedence you need to configure your own resolution strategy before you apply the Spring Boot plugin:

buildscript {
    repositories {
        mavenCentral()
        maven { url 'https://repo.spring.io/libs-snapshot' }
    }
    dependencies {
        classpath 'org.springframework.boot:spring-boot-gradle-plugin:1.3.0.BUILD-SNAPSHOT'
    }
}

apply plugin: 'java'

configurations.compile {
    resolutionStrategy.eachDependency { DependencyResolveDetails details ->
        if (details.requested.group == 'org.springframework') {
            details.useVersion '4.0.0.RELEASE'
        }
    }
}

apply plugin: 'spring-boot'

repositories {
    mavenCentral()
    maven { url 'https://repo.spring.io/libs-snapshot' }
}

dependencies {
    compile 'org.springframework:spring-core'
}

This will give you 4.2.0.RC1 of spring-core:

gradle dependencies --configuration compile
:dependencies

------------------------------------------------------------
Root project
------------------------------------------------------------

compile - Compile classpath for source set 'main'.
\--- org.springframework:spring-core: -> 4.2.0.RC1

BUILD SUCCESSFUL

Total time: 6.188 secs

Furthermore, disabling the dependency management plugin entirely is unlikely to be what people really want. With the plugin disabled a number of Spring Boot's starters will pull in Commons Logging due to Gradle handling exclusions in a Maven pom differently to how Maven handles them. An alternative would be to allow the default bom to be configured. For example you could disable it entirely with:

springBoot {
    dependencyManagementBom = null
}

However, I'm not sure that's even necessary because, as shown above, you can override Boot's dependency management without adding this new configuration option.

To summarise, I'm leaning towards documenting that any resolution strategy configured after the Spring Boot plugin has been applied will run after the dependency management plugin's resolution strategy giving you an opportunity to override its behaviour.

[masc3d]

okay, but in a multi project build resolutions may have been defined before the dependency management plugin to avoid duplication of resolution strategies, eg.

subprojects {
    configurations.all {
        resolutionStrategy {
            failOnVersionConflict()
            ...(more resolutions)
}

another thought would be to have the dependency management plugin at least recognize (it was quite irritating to have runtime breakage without notice just by applying the plugin) or even support resolution strategies defined at a parent level.

[wilkinsona]

AFAIK, you don't have to structure your build like that. Prior to that subprojects block you could have applied the dependency management plugin to the one project that uses it. If I'm mistaken, please let me know.

There's no such thing as a "parent level" in Gradle as, unlike Maven, there's no inheritance hierarchy between projects. If you're interested, there was some discussion about this on the Gradle forum.

[masc3d]

there's certainly a hierarchy thus also a parent level, even if there was no inheritance.
https://docs.gradle.org/current/userguide/organizing_build_logic.html

Inherited properties and methods. In a multi-project build, sub-projects inherit the properties and methods of their parent project.

yes, I could workaround this issue, but is it really a good solution? currently my root project doesn't contain any subproject specifics and I would prefer to keep it that (clean) way.

[masc3d]

btw I have been using ext[..] version overrides as a workaround for now. the main issue is that conflict detection is effectively disabled, so I tried your suggestion of applying the plugin selectively prior to subprojects.

the result is that dependency substitution (eg. resolutionStrategy.eachDependency) works, but failOnVersionConflict and force overrides remain non-functional, so it's essentially no improvement over plain ext overrides.

[wilkinsona]

Can you provide a sample that shows failOnVersionConflict and force not working please? The dependency management plugin doesn't make use of either of those so I'm surprised it has any effect.

[masc3d]

sure, but first to clarify: failOnVersionConflict does not work for any dependency in the bom. Example: I have a child project (a) which requires activemq-5.11.+. Without the dep plugin, the spring-boot project which depends on (a) would raise a version conflict when claiming a different version of activemq. When using the dep plugin it will not, and I'm ending up with inconsistent deps without further notice. Do you still require a sample?

[wilkinsona]

Do you still require a sample?

Yes please

[masc3d]

here you go. https://dl.dropboxusercontent.com/u/3464720/spring-boot-dep-test.zip