JRuby 1.7 and Fedora
bkabrda at redhat.com
Tue Sep 11 11:36:43 UTC 2012
since we have MRI Ruby integrated pretty nicely into Fedora, I started working on JRuby's new upcoming release (1.7) - I'm planning to put it into Fedora 19.
Work already done:
So far, I have updated JRuby's dependencies (in my private repository, none of that has reached Rawhide yet) and made JRuby build and pass tests with Fedora's java libraries.
You can find my work at these places:
 - Source RPMs of JRuby and all updated dependencies
 - A yum repo to use with F19 (you'll probably just want to add it to a mock config for the time being)
 - A github repo with jruby.spec and Fedora specific patches - the spec still has some TODOs, but works. I accept pull requests :)
Work to do:
Most importantly, I'd like to work on integrating JRuby's RubyGems with our system RubyGems, so that JRuby doesn't include (at least in Fedora) its own slightly modified copy. My idea (please shout if you don't like it!) is to hook JRuby into our RubyGems concept :
- All the behaviour mentioned in  will stay.
- JRuby and MRI will load non-platform-specific Gems from the same locations, only the extensions will be placed in different directories.
How to achieve that:
- Ideally push JRuby's changes to RubyGems upstream (not sure if they'd accept them), or just apply them to our Fedora RubyGems downstream for the time being - shouldn't break anything, AFAICS
- Make JRuby work with our custom operating_system.rb  - this would probably require the JRuby's RbConfig::CONFIG to somehow change it's values closer to MRI's
- Figure out the packaging changes around it:
-- Naming Gems that are only for JRuby
-- Placement of JRuby's extensions
-- Creating packages for Gems that have extensions for both JRuby and MRI
-- How to work with ruby(abi) virtual provides - both implementations should have them, but yum currently resolves virtual provides "randomly" (it chooses the provider that has less dependencies, if I'm correct)
I'm cc'ing Charles Nutter in hope that he will join this discussion on ruby-sig :)
If you have any other ideas or you would do something differently, now is the best time to discuss that.
Bohuslav "Slavek" Kabrda.
More information about the ruby-sig