JRuby 1.7 and Fedora
bkabrda at redhat.com
Thu Sep 13 09:16:50 UTC 2012
thanks for getting in loop :)
----- Original Message -----
> Hello all!
> I've copied Tom Enebo on this reply...he may want to get on the list
> > From: "Bohuslav Kabrda" <bkabrda at redhat.com>
> > Hi all,
> > 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 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.
> If this is possible, I don't see an issue. JRuby currently "supports"
> C extensions, but we're deprecating that...so in general the only
> you'll get on JRuby are non-extensions (no platform specified in the
> gem) and -java gems (containing compiled classes or jar files; e.g.
> nokogiri, hpricot, json).
> As long as you can have nokogiri-java and nokogiri C ext installed
> without JRuby *ever* loading the C ext, this should be fine.
Yep, that is the intention.
> > 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
> We have a standing bug to get all of our changes pushed upstream.
> of them are just one-off patches, but there's also our maven support
> (which, I'm sad to say, never really worked like we wanted it to).
> Ideally we could ship stock RubyGems for JRuby 1.7 final.
Great, cool, superb :) That is exactly what Fedora needs.
I will definitely try how that will work with our system rubygems, once that is done.
> > - 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
> File an issue and we can look into it. We largely simulate RbConfig
> since we don't actually have a per-platform build time to populate
I did: , with a patch, too :)
> > - Figure out the packaging changes around it:
> > -- Naming Gems that are only for JRuby
> Any gem that's -java platform will only work on JRuby. There may be
> non -java platform gems that use JRuby-specific features (like Java
> integration) too, however.
As Vit has mentioned, this is basically packaging/naming issue. Still, we will have to be very careful using same gems for MRI and 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)
> So this is basically allowing JRuby to "provide" "ruby" as a
> dependency, right? Yeah ideally we should be able to do that, but of
> course the C extension thing makes it hard for us to replace them
> everywhere (and the Java extension thing makes it hard for them to
> replace us everywhere.
> > I'm cc'ing Charles Nutter in hope that he will join this discussion
> > on ruby-sig :)
> I'm on the list now :)
> FYI, the JRuby 1.7 schedule has us doing a final release around the
> end of this month. Ideally we'd have everything we need changed
> wrapped up ASAP.
> - Charlie
I've been working on and experimenting with the path-rework patch for last two days. As I mentioned, using the default rubygems and doing the path rework as proposed in  should do most of the work. Then we will probably have to adjust our custom operating_system.rb and that should be all.
Thanks for joining the discussion and welcome to Fedora Ruby-sig.
Bohuslav "Slavek" Kabrda.
More information about the ruby-sig