Reenable JRuby #1229
Reenable JRuby #1229
Conversation
headius
force-pushed
the
reenable_jruby
branch
from
f9b5e2a to
b952747
Compare
|
This will need to be re-run after "jruby-head" builds get published overnight tonight or tomorrow. |
|
I did not exclude Windows for now because I don't know why it wouldn't pass. If it fails again I'll look into it or exclude it again. |
|
The JRuby 9.4.9.0 jobs are failing due to the version conflict. The head builds should be ok, but we may want to just remove the non-head jobs until I can figure out a workaround for the jar-dependencies conflict issue (or until JRuby 9.4.10.0 ships with a fix for it). |
By requiring a file from jar-dependencies here, we end up activating whatever the default jar-dependencies gem is for the current JRuby runtime. Later on, when the hook is running or gems that use jars simply try to activate a newer jar-dependencies, we get the dreaded version conflict described in jruby/jar-dependencies#86, preventing activation of all libraries. The change here moves the body of the hook into the JRuby defaults.rb for RubyGems rather than loading any files from jar-dependencies itself. This appears to fix issues like those seen in the jruby-9.4.9.0 builds at ruby/rdoc#1229 (bundle exec failing to run due to the version conflict) and may fix other reports. This does not fix issues using a newer jar-dependencies on an older JRuby, unfortunately.
|
Marked as draft until we can confirm it with patched JRuby builds. |
|
Well, the jruby-head builds have started to pass, but only on macos so far. Continuing to investigate remaining issues. |
|
The additional issue was actually found and fixed later: jruby/jar-dependencies#93 I tried to rebase and re-push but somehow it closed the PR. Please help! |
|
Oops, I can reopen myself.... |
See #1228