How to force version of transitive dependency to not change?

I have an implementation like this

implementation('com.google.code.gson:gson:2.8.6')
implementation('com.squareup.retrofit2:converter-gson:2.6.0') // USES GSON(2.8.5) INTERNALLY
implementation(name: 'sign-library', ext: 'aar') // USES GSON(2.2.4) INTERNALLY

Gradle forces to set each gson transitive dependencies to 2.8.6.

But ‘sign-library’ fails with gson version of 2.8.6

What i want to do is, to let ‘sign-library’ use gson version of 2.2.4 (not 2.8.6)

Hi @blackkara,

If you are using Gradle 6, the preffered way to do this are strict versions. See: https://docs.gradle.org/current/userguide/dependency_downgrade_and_exclude.html#sec:enforcing_dependency_version

In your case:

dependencies {
  implementation('com.google.code.gson:gson:2.2.4!!') { // <- this can also be a 'constraint' if you do not use Gson direction but only want to force it down for 'sign-library'
     because("sign-library does only work with 2.2.4")
  }
  implementation('com.squareup.retrofit2:converter-gson:2.6.0') // USES GSON(2.8.5) INTERNALLY
  implementation(name: 'sign-library', ext: 'aar') // USES GSON(2.2.4) INTERNALLY
}
implementation('com.google.code.gson:gson:2.8.6') // THIS ONE IS REQUIRED!!
implementation('com.squareup.retrofit2:converter-gson:2.6.0') // USES GSON(2.8.5) INTERNALLY
implementation(name: 'sign-library', ext: 'aar') // USES GSON(2.2.4) INTERNALLY

Thanks for reply,

As i mentioned above, our project uses gson(2.8.6) already, we should not ignore this

The only thing i need is to let sign-library use gson version of 2.2.4

@blackkara That’s not possible. If you run Java applications with Gradle it uses a normal Java classpath with the normal class loading. Thus each class can only exist once on the classpath. That’s why Gradle conflict resolves. If you want to use different versions of the same classes in parallel, you need a specific runtime setup - which depends on what kind of Application you are building and what your runtime supports there.

At build time, you could shadow classes. For that you can have a look at: https://imperceptiblethoughts.com/shadow/

But I would reconsider if you really need different versions as it makes things much more complex.

So bad news for me.

Seems we need to support from ‘sign-library’ team to update their internal gson library.

Still can’t believe not having solution for this simple case.

Thanks for interest