'dyno-jedis', 'dyno-redisson', 'dyno-memcache' etc. should not depend on dyno-contrib

[anguenot]

Hey,

The fact that the backend implementations, 'dyno-jedis', 'dyno-redisson', 'dyno-memcache', etc., depend on 'dyno-contrib' brings dependency on Eureka (and underlying dependencies) which is AWS specific. ('eureka-client')

Not only is is not desirable to force AWS specific dependencies to applications not running off AWS, it is a rather a heavy payload to carry for a driver library.

IMHO, all backend implementations should only depend on the 'dyno-core' and AWS specific implementation should be part of 'dyno-contrib' or a AWS specific component.

Let me know if you would be open in discussing this and if you would like me to give it a try with a PR moving AWS specific to 'dyno-contrib' to keep the backend implementations AWS agnostic.

Thanks

J.

[timiblossom]

I think your observation is right. The way we packaged things are reflecting our deployment in AWS. When a user depends on dyno-jedis, it would pull in dyno-core and dyno-contrib (which is currently for AWS friendly deployment).

We'd love to hear you more on how you think we should separate them out for AWS, and non-AWS deployment (or environment deployment agnostic). Note that our internal users are currently pull in dyno-jedis inside their applications. Thanks.

[anguenot]

@timiblossom I will try to find the time this week and come back to you with some info. I believe I have some ideas to keep backward compatibility for your internal users.