Re: JRuby 1.7 and Fedora

[Charles Oliver Nutter]

Hello all!

I've copied Tom Enebo on this reply...he may want to get on the list too.

>  From: "Bohuslav Kabrda" <bkabrda(a)redhat.com&gt;
>
>  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.
Excellent!

>  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 [4]:
>  - All the behaviour mentioned in [4] 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 gems
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.

>  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. Most
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.

>  - Make JRuby work with our custom operating_system.rb [5] - 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 it.

>  - 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.

>  -- 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