guava-retrying
guava-retrying copied to clipboard
rholder
Changing the version range for guava to be strictly maven compatible
The use of '+' in the range isn't strictly supported by maven and can cause issues if using a private repository manager that validates the requests (specifically jfrogs artifactory).
With guava-retrying 2.0.0 as dependency in a Gradle built project, I got guava 21.0-SNAPSHOT resolved although dependency graph shows that all used libraries which also depend on guava, except guava-retrying, specify specific guava release as dependency, and only guava-retrying has range.
Is this PR going to fix this issue?
As current workaround - I explicitly declare dependency on guava (although not using it), and force the resolved version to be fixed, "20.0".
Not a really I'm afraid, the dependency is still open, so the build system is in theory ok to give you any version as long as its > 10.0
Would prefer if fixed version was used, and not a version range. Range just causes issues for common use cases. With fixed dependency version, it's not really forcing the version on guava-retrying users, just clarifies on which specific dependency version was it tested on. User/build using guava-retrying can still have completely different guava version resolved, or have build configured to handle it in specific way.
@tempredirect does it make sense to you that fixed guava dependency version should be used instead? If so, can you please update pull request?
It does indeed make sense to declare a specific version. But which version? It's a harder question than it seems as picking a guava version is a mine field, as things like hadoop don't like newer versions of the library etc.
Also pretty sure @rholder doesn't need me to make that edit for him.
@tempredirect fair enough. @rholder what do you think about using fixed guava dependency version instead of range? Range is causing issues. Fixed version 20 would work for me.
Just ran into this issue: we are about to release our product that uses Guava 20. Because of the dynamic dependency used by guava-retrying, the dependency of our entire project was bumped up to Guava 21 which broke our build. (We reference a method that was in Guava 20 but is not in Guava 21).
Obviously we can get around this in our Gradle build by excluding group "com.google.guava" from the retrying depedency, but it cost me an hour to track down why we were suddenly pulling in Guava 21.
A released library like guava-retrying should not have a dynamic dependency. Since it obviously works with Guava 10, IMO the dependency should be pinned to Guava 10 release.
For what it's worth, the head of master (177b6c9) doesn't compile since something has changed in guava -- Predicate I think. It compiles if I fix the guava dependency to 20.0 it works. If I change it to 21.0, it breaks.
Would prefer if latest guava was used, and just like guava 21+, in new major guava-retrying release start requiring Java 8.