-
Notifications
You must be signed in to change notification settings - Fork 441
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Reenable JRuby #1229
base: master
Are you sure you want to change the base?
Reenable JRuby #1229
Conversation
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 mkristian/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. |
See #1228