rholder / guava-retrying

This is a small extension to Google's Guava library to allow for the creation of configurable retrying strategies for an arbitrary function call, such as something that talks to a remote service with flaky uptime.
Apache License 2.0
1.43k stars 275 forks source link

Lock to RELEASE version of com.google.guava:guava dependency #57

Open marstonstudio opened 8 years ago

marstonstudio commented 8 years ago

With the current configuration of the gradle build file, the dependency on the google guava library currently resolves to 20.0-SNAPSHOT

dependencies {
    compile 'com.google.guava:guava:[10.+,)'
    compile 'com.google.code.findbugs:jsr305:2.0.2'

    // junit testing
    testCompile 'junit:junit:4.11'
    testCompile 'org.mockito:mockito-all:1.9.5'
}

Can we freeze the release version of guava-retrying on a release version of guava? Current setup leads to potential instabilities in case there is a breaking change in the edge version of the underlying dependency.

The workaround in my project pom.xml was to exclude the guava dependency as defined

            <dependency>
                <groupId>com.github.rholder</groupId>
                <artifactId>guava-retrying</artifactId>
                <version>2.0.0</version>
                <exclusions>
                    <exclusion>
                        <groupId>com.google.guava</groupId>
                        <artifactId>guava</artifactId>
                    </exclusion>
                </exclusions>
            </dependency>
            <dependency>
                <groupId>com.google.guava</groupId>
                <artifactId>guava</artifactId>
                <version>19.0</version>
            </dependency>
JensRantil commented 8 years ago

We've had a similar issue. On a larger scale, is guava-retrying using Guava that much to really require Guava? That is, would it make sense to create a utils class with the Guava stuff being used? Guava is a very common library used by projects that uses guava-retrying. One less potential Guava version conflict would be nice.

Let me know if this would make sense I might be able to have a quick glance over the code to see if this refactoring is a lot of work or not.