Dependency being pulled in on some machines, but not others

Help/Discuss
1

I have a Gradle build that is pulling in a Gradle dependency on a local library for no apparent reason. The library is a set of artifacts that is included in the build as an included build.

On my dev box:

$ git log -1 | head -1
commit 30965f45c578089301ab579be71fecb2cc2f5b82

$ ./gradlew --version

------------------------------------------------------------
Gradle 5.2.1
------------------------------------------------------------

Build time:   2019-02-08 19:00:10 UTC
Revision:     f02764e074c32ee8851a4e1877dd1fea8ffb7183

Kotlin DSL:   1.1.3
Kotlin:       1.3.20
Groovy:       2.5.4
Ant:          Apache Ant(TM) version 1.9.13 compiled on July 10 2018
JVM:          11.0.2 (Oracle Corporation 11.0.2+7-LTS)
OS:           Linux 4.20.3-200.fc29.x86_64 amd64

# Use env CI=true here just to make sure this isn't the cause of any differences
$ env CI=true ./gradlew dependencyInsight --dependency jjwt-api --configuration runtimeClasspath
Configuration on demand is an incubating feature.

> Task :dependencyInsight
No dependencies matching given input were found in configuration ':runtimeClasspath'

Deprecated Gradle features were used in this build, making it incompatible with Gradle 6.0.
Use '--warning-mode all' to show the individual deprecation warnings.
See https://docs.gradle.org/5.2.1/userguide/command_line_interface.html#sec:command_line_warnings

BUILD SUCCESSFUL in 2s
1 actionable task: 1 executed

and on m CI box:

$ git log -1 | head -1
commit 30965f45c578089301ab579be71fecb2cc2f5b82

$ ./gradlew --version

------------------------------------------------------------
Gradle 5.2.1
------------------------------------------------------------

Build time:   2019-02-08 19:00:10 UTC
Revision:     f02764e074c32ee8851a4e1877dd1fea8ffb7183

Kotlin DSL:   1.1.3
Kotlin:       1.3.20
Groovy:       2.5.4
Ant:          Apache Ant(TM) version 1.9.13 compiled on July 10 2018
JVM:          11.0.1 (Oracle Corporation 11.0.1+13-Ubuntu-3ubuntu116.04ppa1)
OS:           Linux 4.15.0-1037-azure amd64

$ env CI=true ./gradlew dependencyInsight --dependency jjwt-api --configuration runtimeClasspath
Configuration on demand is an incubating feature.

> Task :dependencyInsight
io.jsonwebtoken:jjwt-api:0.10.5 FAILED
   Selection reasons:
      - By constraint : Dependency locking
   Failures:
      - Dependency lock state out of date:
          - Resolved 'io.jsonwebtoken:jjwt-api:0.10.5' which is not part of the dependency lock state

io.jsonwebtoken:jjwt-api:0.10.5 FAILED
+--- runtimeClasspath
+--- project :lib-kotlin:lib-sec
|    \--- project :lib-kotlin:lib-grpc
|         \--- runtimeClasspath (requested com.redock.lib-kotlin:lib-grpc:1.5-SNAPSHOT)
+--- io.jsonwebtoken:jjwt-impl:0.10.5
|    \--- project :lib-kotlin:lib-sec (*)
\--- io.jsonwebtoken:jjwt-jackson:0.10.5
     \--- project :lib-kotlin:lib-sec (*)

(*) - dependencies omitted (listed previously)

A web-based, searchable dependency report is available by adding the --scan option.

Deprecated Gradle features were used in this build, making it incompatible with Gradle 6.0.
Use '--warning-mode all' to show the individual deprecation warnings.
See https://docs.gradle.org/5.2.1/userguide/command_line_interface.html#sec:command_line_warnings

BUILD SUCCESSFUL in 4s
1 actionable task: 1 executed

The dev box is correct, the CI box isn’t. Why would the same version of Gradle, with the same underlying code, behave differently on two different machines? This seems like a big problem…

I’ve noticed this only recently because I enabled dependency locking, and this is failing in the CI environment because it is looking for that dependency in the lock files, and then failing because that dependency (correctly) isn’t there.

2

Is it possible the SNAPSHOT has added a new dependency between when your local machine used it and when remote did?

i.e. does --refresh-dependencies also break your local machine?

3

Nope, --refresh-dependencies does not break my dev machine, nor does it fix the CI machine. In fact, the SNAPSHOT dependency is not being used at all, because a) lib-grpc is actually not a dependency of that project at all, and b) even if were, it would be replaced via a composite build with a local source tree, on both the dev box and the CI box.

4

Ok, hmm, it seems to be working now. Its possible there may have been a Gradle version mismatch between the lib project and the caller project. I’m not actually sure what happened actually – in any case it seems to be working now, with a rebase of the branch to correct some Gradle wrapper versions and a force push.