Proposed F19 Feature: JRuby 1.7 - JRuby is an alternative Ruby implementation

[Jaroslav Reznik]

As decided by FESCo on 2012-12-05 meeting, all proposed Features are required
to pass through the community review by announcing them on devel-announce list.
FESCo votes on new features no sooner than a week from the announcement.

= Features/JRuby 1.7 =
https://fedoraproject.org/wiki/Features/JRuby_1.7

* Detailed description:
Transition to JRuby 1.7 will consist of 3 basic steps:

- Updating packages
 Most of the packages that JRuby depends on are in Fedora just because of JRuby, 
 so they can be safely updated.
 Some dependencies are shared with other packages, so they will have to be 
 discussed with their owners (see #Scope). 

- Integration with Fedora
 Normally, each Ruby implementations ships with its own copy of RubyGems 
 library. This is wrong because a) it's bundling, b) there is no reason 
 why multiple Ruby implementations wouldn't be able to share one RubyGems 
 library. There used to be some differencies in JRuby's copy of RubyGems, 
 but the JRuby upstream has been very cooperative and managed to get them 
 all merged into upstream RubyGems.
 The integration will require changing Fedora's operating_system.rb (place 
 for distro-specific defaults for RubyGems). This change will result into 
 all Gems with binary extensions having to be recompiled, as the binary 
 extension placement will change. See [1] for current operating_system.rb 
 look and its changes from F18.
 What should "/usr/bin/ruby" point to? During standard Gem packaging process,
 the executable files in Gems get shebangs according to the binary that they
 are packaged with (Ruby => "/usr/bin/ruby"; JRuby => "/usr/bin/jruby"). 
 Therefore executing a Ruby "binary" runs the interpreter that was used for 
 building (or the hardcoded one, which is usually Ruby). Using alternatives 
 for "/usr/bin/ruby" doesn't seem to be a very good option, because Ruby and
 JRuby are not in fact full alternatives, as they for example cannot use same
 extension Gems (but it still makes sense to allow executing same binaries 
 with them). Also, alternatives are only switchable on admin level (we want
 every developer with non-root privileges to be able to choose the 
 interpreter). Therefore Ruby-SIG has come up with solution of having 
 "/usr/bin/ruby" as a bash script (currently called rubypick) [2], that 
 allows user to choose the interpreter as first argument on invocation 
 (_mri_ or _jruby_), if such a parameter is present. Otherwise it falls 
 back to a default. For example invoking "ruby_binary _jruby_ --foo=bar" 
 in fact invokes "/usr/bin/jruby ruby_binary --foo=bar". This bash script 
 will be in a separate package and both Ruby and JRuby will depend on it.
 Ruby-SIG knows that this feature might be controversial and we wouldn't 
 want it to stop us from bringing JRuby's power to Fedora (if met with a 
 heavy resistance). So if anyone will suggest a more suitable solution, 
 we'll go with it instead of this one. 
    
- Changes in packaging
 None yet. JRuby will be able to use pure Ruby Gems packaged into RPM out of 
 the box, but packaging of Gems with JRuby extensions is turning out to be 
 very complicated, so the guidelines for it will be postponed to next release 
 (as well as the actual packaging). Users will be still able to install Gems 
 with JRuby extensions, both system-wide (into /usr/local/) and into their 
 home directories. 

[1] https://github.com/bkabrda/jruby.spec/blob/master/rubygems/operating_system.rb
[2] https://github.com/bkabrda/rubypick