Hi Charles,
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
too.
> From: "Bohuslav Kabrda" <bkabrda(a)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.
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.
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.
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.
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 [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.
I did: [1], 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 [1]
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.
Slavek.
--
Regards,
Bohuslav "Slavek" Kabrda.
[1]
http://jira.codehaus.org/browse/JRUBY-6890