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" <[email protected]> > > > > 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 _______________________________________________ ruby-sig mailing list [email protected] https://admin.fedoraproject.org/mailman/listinfo/ruby-sig
