Coverage remained the same at 90.94% when pulling 95cebfc on aw:dont-relax-rest-client into bb40b39 on lemurheavy:master.

Coverage decreased (-0.23%) to 90.71% when pulling 169aed1 on aw:dont-relax-rest-client into bb40b39 on lemurheavy:master.

Coverage remained the same at 90.94% when pulling 9fbde31 on aw:dont-relax-rest-client into bb40b39 on lemurheavy:master.

Instead of holding back rest-client, I’d rather see this problem solved by creating a Java-native version of unf_ext.

/cc @headius @enebo @knu

There is already a Java version of unf, which does not depend on unf_ext.

🆒 In that case, I don’t think think this change is necessary. FWIW, the build is passing on JRuby 1.7.19 without this change.

What's the original problem, anyway?

Perhaps I wasn't clear.

It's not this gem's build that fails, it's gems that depend on this one which fail (on JRuby only), because of the newer rest-client dependency.

Example: https://travis-ci.org/aw/CacheRules/jobs/57634366

I see. I think the problem lies where Gemfile.lock generated by and for CRuby is used for JRuby. The two implementations of ruby often have different sets of dependencies, and in such a case a Gemfile.lock file cannot be shared between them.

In this case, I'd suggest simply removing Gemfile.lock from the repository especially when it is hosting a gem not an application. Here's a nice article to show you why: http://yehudakatz.com/2010/12/16/clarifying-the-roles-of-the-gemspec-and-gemfile/

Oh that's interesting.. I didn't know this about the Gemfile.lock. Thanks for the link, I'll try it out and report back.

@knu Good catch! I'll close this issue/pr. Thanks for the tip 🌸 🍶

Glad it worked! 🍡 🍵