Repository navigation
Google Cloud components should not depend on -android versions #4440
Description
Currently, the google-cloud-logging-logback component depends on Guava version 26.0-andriod. This is not appropriate for Google Cloud projects which are running on a full JDK in e.g. GKE. The two different versions are not considered compatible by Maven and version checker plugins.
It looks like this issue was introduced in #3980
Environment details
- OS: Fedora Linux 29
- Java version: JDK 11
- google-cloud-java version(s):
0.79.0-alpha
Steps to reproduce
- Use Guava
- Import
google-cloud-logging-logback - Run a build checker that ensures dependency convergence
Stacktrace
[INFO] --- maven-dependency-versions-check-plugin:2.0.2:check (default) @ mycorp-server ---
[INFO] Checking dependency versions
[ERROR] Found a problem with the direct dependency com.google.guava:guava of the current project
Expected version is 26.0-jre
Resolved version is 26.0-jre
Version 26.0-android was expected by artifact: com.google.cloud:google-cloud-logging-logback
Version 26.0-jre was expected by artifacts: com.mycorp.components:mycorp-jaxrs-client, com.mycorp.components:mycorp-spring
Activity
stevenschlansker commentedon Feb 4, 2019
Additionally, the docs specify that Google Cloud components aren't even compatible with Android:
(https://cloud.google.com/logging/docs/setup/java)
so it's even stranger to depend on
26.0-androidversion.sduskis commentedon Feb 4, 2019
We base our guava version based on grpc, which currently uses 26.0-android.
@ejona86, do you have any comments about the history of the selection of the guava version?
sduskis commentedon Feb 4, 2019
Would it make sense for us to exclude grpc's dependency on
-androidand use-jreinstead?sduskis commentedon Feb 4, 2019
Oh... I see. @andreamlin commented:
Our libraries need to support JDK 7, but the
-jreversion supports 8+ only.ejona86 commentedon Feb 4, 2019
The android version can be used for two things: 1) android support, 2) JDK 7 support. google-cloud-java supports JDK 7, so the -android version is required.
Note that Maven's output looks like what I'd expect. There's no bug here. It is complaining that the version was downgraded from 26.0-jre to 26.0-android (because 'j' in jre is greater than 'a' in android). So this is the same sort of error you get with 25.0 vs 26.0. You need to add the higher version of Guava to your dependencies, or reorder your dependencies.
ejona86 commentedon Feb 4, 2019
Wait a minute. That output does look strange. Why is Maven complaining? "Expected version is 26.0-jre" and "Resolved version is 26.0-jre"... so what's the issue?
@stevenschlansker, oh, you're using dependencyConvergence? Dependency Convergence adds pain for no benefit. I strongly recommend requireUpperBoundDeps instead. In any case when using dependencyConvergence these sorts of errors will crop up and you have to manually address it (via exclusions which is part of why dependencyConvergence should not be used).
stevenschlansker commentedon Feb 4, 2019
I understand that it can be resolved in each project by explicitly resolving the conflict -- however pushing this onto every downstream user is not great. It's not quite the same as
25vs26as both jars really are version26. (Wouldjdkvsandroidbe more appropriate as aclassifier?)I guess ideally Guava would be split into
guava-apiand thenguava-impl-jdkandguava-impl-androidbut that's probably asking far too much.I can play around with
requireUpperBoundDepsbut my previous experience with Maven version checkers was that they generally understand-alpha-betaand-rclike version, but basically anything else it gives up and says "these versions aren't compatible".Per https://maven.apache.org/ref/3.3.3/maven-artifact/apidocs/org/apache/maven/artifact/versioning/ComparableVersion.html it should be alphabetically sorted, but relying on this behavior over making the versioning more sane seems like a really unfortunate decision - inherently one is "greater" than the other, but which one you want is context dependent. If
android > jre, then yourandroidbuild correctly seesandroidas the upper bound, butjredoes not. Ifjre > androidvice versa.ejona86 commentedon Feb 5, 2019
androidis a subset of thejreAPI (so no,guava-apiwouldn't work), so it is correct thatandroid < jre. I agree there can be problems in cases like25.0-jre < 26.0-android. But there's also not many alternatives (and no, classifier doesn't work).Complaints about Guava's versioning system should be filed at https://github.com/google/guava and not here. It's already been made clear that
-androidis the appropriate and necessary version for this project.requireUpperBoundDepsshould work much better thandependencyConvergence. For example, there is no need to<exclude>dependencies (which can break future upgrades) and it properly checks even if<dependencyManagement>is in use.sduskis commentedon Feb 5, 2019
I don't think that we can do much on this repo. I'm going to close this issue since there isn't anything actionable for this repo. @ejona86 suggested alternative repos in which this investigation can proceed.