"Dependency failing" when used with latest "google-services"

[Former user]

This is the error we are getting:

FAILURE: Build failed with an exception.

* What went wrong:
Failed to capture snapshot of input files for task ':app:checkCdialoguesDebugClasspath' property 'compileClasspath' during up-to-date check.
> In project 'app' a resolved Google Play services library dependency depends on another at an exact version (e.g. "[1.3.1
  ,2.3]", but isn't being resolved to that version. Behavior exhibited by the library will be unknown.

  Dependency failing: com.nimbusds:nimbus-jose-jwt:5.1 -> net.minidev:json-smart@[1.3.1,2.3], but json-smart version was 2
  .3.

  The following dependencies are project dependencies that are direct or have transitive dependencies that lead to the art
  ifact with the issue.
  -- Project 'app' depends on project 'react' which depends onto com.nimbusds:nimbus-jose-jwt@5.1

More info on these issues here: https://github.com/invertase/react-native-firebase/issues/1676 https://github.com/Microsoft/react-native-code-push/issues/1448

[Connect2id OSS]

Hi,

We're not really familiar with those projects, but if you can demonstrate it's an issue with the JWT lib or its pom.xml we'd be glad to help out.

[David Syer]

The problem is with this library. You need to use a fixed version of dependencies, not ranges. The range is causing dependency resolution to fail in many downstream projects, including ones that I work on, mainly because the Azure Maven tooling uses this library. It's probably not literally your fault in this case, but it's too fragile to risk using the version range feature in a library at all, especially if you depend on other libraries that you do not control and put ranges in those dependencies. Please fix this and let users override versions if they want to.

See also https://bitbucket.org/connect2id/oauth-2.0-sdk-with-openid-connect-extensions/issues/261/please-dont-use-version-ranges-in-library

[Connect2id OSS]

What is a good strategy to choose a version? Set the lowest compatible, e.g. 1.3.1?

[David Syer]

That would work. Lowest compatible with no security patches is probably a better policy.

[Clemens]

The root cause for both referenced issue is google/play-services-plugins#30. The correct workaround in the meantime is to set com.google.gms.googleservices.GoogleServicesPlugin.config.disableVersionCheck = true in build.gradle.

Are you suggesting that Java libraries in general should stop using the version range feature because of this bug? Because that seems unreasonable to me. Am I missing something here?

[Vladimir Dzhuvinov]

@drizzd Amen!

I suggest we keep this open because fixing things by breaking other stuff is just insane :)

[Stéphane Nicoll]

Are you suggesting that Java libraries in general should stop using the version range feature because of this bug?

Java libraries and anything in general should stop using version ranges because it's not a very stable feature IMO. This makes your build non reproductible for a start so I'd avoid that only for that reason.

If you checkout a release tag and you build the binary, the build may fail as the range could bring you a different version for a dependency than the one you built the release against. That seems totally unreasonable to me.

[Yavor Vasilev]

The net.minidev:json-smart:* dependency was shaded in v9.0.