Gradle doesn't allow me to override snakeyaml:1.6 to snakeyaml:1.10

The project at https://github.com/gesellix/gradle-global-dependencies shows that I cannot force Gradle to use the dependency ‘org.yaml:snakeyaml:1.10’, but always gives me an older version (looks like org.yaml:snakeyaml:1.6). It looks like Gradle ignores user dependencies which are included in the Gradle distribution.

Is it possible to force Gradle to accept such user defined dependency versions?

Hey Tobias, this is a known limitation of using gradleApi in your projects. There are some issues listed to track this:

A (relative inconvenient) workaround I can think of might be explicitly add the gradle dependencies. Depending of your plugin ,you might just need gradle-core jar.

cheers, René

Something like this might work:

dependencies {

compile gradleApi()

compile “org.yaml:snakeyaml:1.10” }

sourceSets {

main {

compileClasspath = compileClasspath.filter { !it.name.contains(“snakeyaml-1.6”) }

} }

@Rene: explicitly adding the gradle dependencies really sounds quite inconvenient, especially when it comes to gradle updates :wink: @Peter: this didn’t work for me. It seems like the gradle dependencies are loaded into the classpath at another phase, but your idea looks like it should work.

Until know I thought Gradle would also use its dependency resolution mechanism, but looking at the DependencyClassPathProvider there’s much manual classpath manipulation going on. Would it be possible for me to hook into the DependencyClassPathProvider or ModuleRegistry for skipping the PluginModules?

Do you know if Gradle will get a fix regarding the gradleApi (and localGroovy) dependency issues?

Thanks!

I guess additionally to the snippet Peter provided above you need to filter the snake-yaml lib also from the test classpath:

test.doFirst {
 classpath = classpath.filter { !it.name.contains("snakeyaml-1.6") }
}

This should do the trick.

We have some plans to improve the overall experience of plugin authors and provide a better way to declare dependencies on the gradle functionality. Fixing gradleApi() behaviour is currently not on the top of our priority list though.

cheers, René

yay, that works, thank you so much!