Say we have a large dependency graph in which Scala dependencies foo:bar:5.0 and foo:bar_2.10:6.0 are pulled in transitively. These two modules are the same for all intents and purposes, but can’t natively be resolved by Gradle. As far as I can tell, there’s no Gradle API to directly flatten these t…

If I understand correctly, you would like Gradle to enter conflict resolution for foo:bar:5.0 and foo:bar_2.10:6.0. And for the moment, it does not since they have different module name. On its way to 5.0 a feature was added to Gradle that could help in this case: capabilities It enables dependen…

I think you can use a module replacement rule Eg dependencies { modules { module("foo:bar") { replacedBy("foo:bar_2", "bar was renamed to bar_2") } } }

Thanks for getting back to me, @Lance @ljacomet In our case, we don’t necessarily know the group or module name prior to resolution, and require a more flexible replacement strategy that can deduce replaceable modules during resolution time. It sounds like this may not be supported yet, so I’d like…

Hmmm… seems similar to what we’re already doing. I’ll play around with it, thanks!

Proper way to resolve transitive modules with and without Scala variants

Help/Discuss

Lance (uklance) June 18, 2018, 5:40am 5

Perhaps you could use a component selection rule similar to here

Topic		Replies	Views
User customizable conflict resolution failure Help/Discuss	6	836	October 18, 2017
How to force a version of a transitive dependency without hardcoding the version number Old Forum Archive	6	1924	October 23, 2012
Scala plugin erroneous compiler version inference with transitive dependencies Old Forum Archive	4	1823	January 17, 2014
Dependency resolution picking the wrong version (overly optimistic resolution strategy) Old Forum Archive	3	2919	January 12, 2015
Transitive vs module dependency issue Help/Discuss	2	684	November 22, 2017

Proper way to resolve transitive modules with and without Scala variants

Related topics