JRuby 1.7.0 progress

[Bohuslav Kabrda]

Hi folks,
I'm writing a quick summary of what I managed to achieve with JRuby/Fedora implementation so far. You can try out my repo at [1] and see the progress of work on jruby.spec at [2].
- I have managed to remove the RubyGems copy from JRuby and make them work with our system RubyGems - I had to apply few JRuby specific patches there - two are already accepted upstream, but not merged into the 1.8 tree, one is still pending [3]. The updated RubyGems are also in the mentioned repo and please be careful when installing them, preferably use mock.*
- As a part of the RubyGems modifications, I have also prepared a sample gem (rubygem-json, also in the repository), with a rubygem-json-java subpackage, that provides Java extensions for JRuby.
- Pure Gems from Fedora now work with JRuby out of the box, no modification needed.
- "jgem" command works exactly as "gem", only using JRuby - nice, isn't it? :)
- load paths set has been brought much closer to MRI, which allowed most of the stuff I have done

TODO:
- I'm still unsure what is the best way to set up the Provides/Requires, so that RubyGems would be installable without MRI, only with JRuby. I guess we can live with JRuby dragging in Ruby, that's a small problem for now :)
- Some modifications to Guidelines will be needed, explaining how to build Gems/non-Gems for JRuby.
- I will also add a jruby-devel package with macros.jruby to match MRI's behaviour closely.

* The reason for this is, that I have also tried to introduce new naming scheme for Gems extensions dirs, which is not compatible with the current one. So far, the %gem_extdir was "/usr/lib[64]/gems/exts". With Rubinius and JRuby comming, there is a slight problem - extensions for JRuby should of course go under /usr/share/gems/exts, but Rubinius extensions would have problems, as they should go under %gem_extdir, too. Therefore, I'd like to propose this scheme for extension placement:
%gem_extdir %{_libdir}/gems/ruby # MRI
%xgem_extdir %{_libdir}/gems/rubinius # Rubinius, not sure if that should be named "xgem_extdir", what do the others think?
%jgem_extdir %{_datadir}/gems/jruby #JRuby # JRuby
This logic to implement this is very simple and it all goes to defaults/operating_system.rb in the updated rubygems package in my repo (specfile is a bit adjusted, too).
There is also a question of versioning these dirs, mainly Rubinius exts, but I'm leaving that for future, comment if you have any good ideas :)

Thanks goes to Charles Nutter for taking the JRuby RubyGems close to upstream, which was very important from Fedora integration POV :)

Slavek.

[Vít Ondruch]

Hi Slavek!

Great effort, although I did not have a chance to test your packages 
yet, since I am busy with getting Rubinius in shape ;)

My general interest are the naming conventions. It seems that you are 
going to use
* "j" prefix, such as jgem or %{jgem_extdir}
* -java suffix, for jruby subpackage
* jruby subdirectory for extensions

But I would suggest to always use suffix instead and for consistency, I 
vote for "{-,_}jruby". E.g. you would get gem-jruby, 
%{gem_extdir_jruby}, json-jruby and finally %{_datadir}/gems/jruby. Note 
that I am afraid that the -java suffix becomes problematic in case, when 
one day there will be introduced other alternative implementation of 
Ruby in Java

For Rubinius, we would go either with -rubinius suffix, or -rbx, which 
is shorter. However, there might be some complications with 
%{gem_extdir_rubinius}, since ATM, it seems that binary extensions 
compatible with Rubiniuses 1.8 mode are not compatible with Rubiniuses 
1.9 mode (but I hope I am wrong).

And one more comment about the jgem. I am asking myself if that is good 
idea to provide such jruby specific executables (although jgem might be 
good candidate for exception), since it would imply that every gem has 
to have its executable for different Ruby implementations etc. However, 
I believe, that user is not interested which interpreted is used to 
execute his program, as long as he gets the result. Therefore, the 
distinction between gem and jgem is just implementation detail IMO and 
should not be exposed, (but I might be proven wrong ;).

Vit

Dne 8.10.2012 15:44, Bohuslav Kabrda napsal(a):
> Hi folks,
> I'm writing a quick summary of what I managed to achieve with JRuby/Fedora implementation so far. You can try out my repo at [1] and see the progress of work on jruby.spec at [2].
> I have managed to remove the RubyGems copy from JRuby and make them work with our system RubyGems - I had to apply few JRuby specific patches there - two are already accepted upstream, but not merged into the 1.8 tree, one is still pending [3]. The updated RubyGems are also in the mentioned repo and please be careful when installing them, preferably use mock.*
> As a part of the RubyGems modifications, I have also prepared a sample gem (rubygem-json, also in the repository), with a rubygem-json-java subpackage, that provides Java extensions for JRuby.
> Pure Gems from Fedora now work with JRuby out of the box, no modification needed.
> "jgem" command works exactly as "gem", only using JRuby - nice, isn't it? :)
> load paths set has been brought much closer to MRI, which allowed most of the stuff I have done
>
> TODO:
> I'm still unsure what is the best way to set up the Provides/Requires, so that RubyGems would be installable without MRI, only with JRuby. I guess we can live with JRuby dragging in Ruby, that's a small problem for now :)
> Some modifications to Guidelines will be needed, explaining how to build Gems/non-Gems for JRuby.
> I will also add a jruby-devel package with macros.jruby to match MRI's behaviour closely.
> The reason for this is, that I have also tried to introduce new naming scheme for Gems extensions dirs, which is not compatible with the current one. So far, the %gem_extdir was "/usr/lib[64]/gems/exts". With Rubinius and JRuby comming, there is a slight problem - extensions for JRuby should of course go under /usr/share/gems/exts, but Rubinius extensions would have problems, as they should go under %gem_extdir, too. Therefore, I'd like to propose this scheme for extension placement:
>
> %gem_extdir %{_libdir}/gems/ruby # MRI
> %xgem_extdir %{_libdir}/gems/rubinius # Rubinius, not sure if that should be named "xgem_extdir", what do the others think?
> %jgem_extdir %{_datadir}/gems/jruby #JRuby # JRuby
> This logic to implement this is very simple and it all goes to defaults/operating_system.rb in the updated rubygems package in my repo (specfile is a bit adjusted, too).
> There is also a question of versioning these dirs, mainly Rubinius exts, but I'm leaving that for future, comment if you have any good ideas :)
>
> Thanks goes to Charles Nutter for taking the JRuby RubyGems close to upstream, which was very important from Fedora integration POV :)
>
> Slavek.

[Bohuslav Kabrda]

Hi Vit,
thanks for your comments!

----- Original Message -----
> Hi Slavek!
>
> Great effort, although I did not have a chance to test your packages
> yet, since I am busy with getting Rubinius in shape ;)
>
> My general interest are the naming conventions. It seems that you are
> going to use
> "j" prefix, such as jgem or %{jgem_extdir}
> -java suffix, for jruby subpackage
> jruby subdirectory for extensions
>
> But I would suggest to always use suffix instead and for consistency,
> I
> vote for "{-,_}jruby". E.g. you would get gem-jruby,
> %{gem_extdir_jruby}, json-jruby and finally %{_datadir}/gems/jruby.

Good point. As for now, I haven't really been thinking about this into great detail, I just wanted to make it work - but you proposal makes good sense.
* I will rename %{jgem_extdir} to %{gem_extdir_jruby}
* The jruby subdirectory is already used for extensions, if I'm not mistaken.

As for the Gem subpackages, I am not entirely convinced about the -jruby suffix.
Pros of -jruby suffix:
- Consistency (everything that has to do something with JRuby has "jruby" in its name)
Cons:
- The rubygems.org precompiled Gems for JRuby (that we are substituting here) have "-java" suffix. The reason why I chose to follow that is to follow the upstream (meaning precompiled stuff from rubygems.org) naming convention. On the other hand, I agree that when using "yum install rubygem-json<tabtab>" and rubygem-json-jruby appears, it is a pretty clear situtation :)
> Note
> that I am afraid that the -java suffix becomes problematic in case,
> when
> one day there will be introduced other alternative implementation of
> Ruby in Java
>
> For Rubinius, we would go either with -rubinius suffix, or -rbx,
> which
> is shorter. However, there might be some complications with
> %{gem_extdir_rubinius}, since ATM, it seems that binary extensions
> compatible with Rubiniuses 1.8 mode are not compatible with
> Rubiniuses
> 1.9 mode (but I hope I am wrong).

Yes, this might turn out to be a problem. I'll leave the extdirs mechanism as it is for now and when we find out whether versioning is needed, we can reopen this discussion.
> And one more comment about the jgem. I am asking myself if that is
> good
> idea to provide such jruby specific executables (although jgem might
> be
> good candidate for exception), since it would imply that every gem
> has
> to have its executable for different Ruby implementations etc.
> However,
> I believe, that user is not interested which interpreted is used to
> execute his program, as long as he gets the result. Therefore, the
> distinction between gem and jgem is just implementation detail IMO
> and
> should not be exposed, (but I might be proven wrong ;).

I don't agree with you here. Consider our way of local installation - user runs "gem install foo" and that installs the foo gem into his home directory. But that would only install the MRI version of the gem. For installing JRuby version, the user would be forced to run "jruby /usr/bin/gem" - that is why I would prefer "gem-jruby". As for the "*-jruby" executables, I would vote for providing the "core" ones: "gem-jruby" and "irb-jruby".
> Vit
>
> Dne 8.10.2012 15:44, Bohuslav Kabrda napsal(a):
> > Hi folks,
> > I'm writing a quick summary of what I managed to achieve with
> > JRuby/Fedora implementation so far. You can try out my repo at [1]
> > and see the progress of work on jruby.spec at [2].
> > I have managed to remove the RubyGems copy from JRuby and make
> >
> > them work with our system RubyGems - I had to apply few JRuby
> > specific patches there - two are already accepted upstream, but
> > not merged into the 1.8 tree, one is still pending [3]. The
> > updated RubyGems are also in the mentioned repo and please be
> > careful when installing them, preferably use mock.*
> > As a part of the RubyGems modifications, I have also prepared a
> >
> > sample gem (rubygem-json, also in the repository), with a
> > rubygem-json-java subpackage, that provides Java extensions for
> > JRuby.
> > Pure Gems from Fedora now work with JRuby out of the box, no
> >
> > modification needed.
> > "jgem" command works exactly as "gem", only using JRuby - nice,
> >
> > isn't it? :)
> > load paths set has been brought much closer to MRI, which allowed
> >
> > most of the stuff I have done
> >
> > TODO:
> > I'm still unsure what is the best way to set up the
> >
> > Provides/Requires, so that RubyGems would be installable without
> > MRI, only with JRuby. I guess we can live with JRuby dragging in
> > Ruby, that's a small problem for now :)
> > Some modifications to Guidelines will be needed, explaining how
> >
> > to build Gems/non-Gems for JRuby.
> > I will also add a jruby-devel package with macros.jruby to match
> >
> > MRI's behaviour closely.
> > The reason for this is, that I have also tried to introduce new
> >
> > naming scheme for Gems extensions dirs, which is not compatible
> > with the current one. So far, the %gem_extdir was
> > "/usr/lib[64]/gems/exts". With Rubinius and JRuby comming, there
> > is a slight problem - extensions for JRuby should of course go
> > under /usr/share/gems/exts, but Rubinius extensions would have
> > problems, as they should go under %gem_extdir, too. Therefore, I'd
> > like to propose this scheme for extension placement:
> > %gem_extdir %{_libdir}/gems/ruby # MRI
> > %xgem_extdir %{_libdir}/gems/rubinius # Rubinius, not sure if that
> > should be named "xgem_extdir", what do the others think?
> > %jgem_extdir %{_datadir}/gems/jruby #JRuby # JRuby
> > This logic to implement this is very simple and it all goes to
> > defaults/operating_system.rb in the updated rubygems package in my
> > repo (specfile is a bit adjusted, too).
> > There is also a question of versioning these dirs, mainly Rubinius
> > exts, but I'm leaving that for future, comment if you have any
> > good ideas :)
> >
> > Thanks goes to Charles Nutter for taking the JRuby RubyGems close
> > to upstream, which was very important from Fedora integration POV
> > :)
> >
> > Slavek.
>
> ruby-sig mailing list
> [e-mail]
> https://admin.fedoraproject.org/mailman/listinfo/ruby-sig

[Vít Ondruch]

Dne 9.10.2012 08:19, Bohuslav Kabrda napsal(a):
> > And one more comment about the jgem. I am asking myself if that is
> > good
> > idea to provide such jruby specific executables (although jgem might
> > be
> > good candidate for exception), since it would imply that every gem
> > has
> > to have its executable for different Ruby implementations etc.
> > However,
> > I believe, that user is not interested which interpreted is used to
> > execute his program, as long as he gets the result. Therefore, the
> > distinction between gem and jgem is just implementation detail IMO
> > and
> > should not be exposed, (but I might be proven wrong ;).
>
> I don't agree with you here. Consider our way of local installation - user runs "gem install foo" and that installs the foo gem into his home directory. But that would only install the MRI version of the gem. For installing JRuby version, the user would be forced to run "jruby /usr/bin/gem" - that is why I would prefer "gem-jruby". As for the "*-jruby" executables, I would vote for providing the "core" ones: "gem-jruby" and "irb-jruby".

Yes, that was exactly why I mentioned that jgem/gem-jruby might be 
candidate for exception ;)

BTW, isn't there for JRuby something like in Rubinius, such as you can 
call "rbx -S rake" to execute rake, so you don't have to specify full 
path to script.

Vit

[Bohuslav Kabrda]

----- Original Message -----
> Dne 9.10.2012 08:19, Bohuslav Kabrda napsal(a):
> > > And one more comment about the jgem. I am asking myself if that is
> > > good
> > > idea to provide such jruby specific executables (although jgem
> > > might
> > > be
> > > good candidate for exception), since it would imply that every gem
> > > has
> > > to have its executable for different Ruby implementations etc.
> > > However,
> > > I believe, that user is not interested which interpreted is used
> > > to
> > > execute his program, as long as he gets the result. Therefore, the
> > > distinction between gem and jgem is just implementation detail IMO
> > > and
> > > should not be exposed, (but I might be proven wrong ;).
> >
> > I don't agree with you here. Consider our way of local installation
> > user runs "gem install foo" and that installs the foo gem into
> >
> > his home directory. But that would only install the MRI version of
> > the gem. For installing JRuby version, the user would be forced to
> > run "jruby /usr/bin/gem" - that is why I would prefer "gem-jruby".
> > As for the "*-jruby" executables, I would vote for providing the
> > "core" ones: "gem-jruby" and "irb-jruby".
>
> Yes, that was exactly why I mentioned that jgem/gem-jruby might be
> candidate for exception ;)
>
> BTW, isn't there for JRuby something like in Rubinius, such as you
> can
> call "rbx -S rake" to execute rake, so you don't have to specify full
> path to script.

"jruby -S rake" works too, of course. Nice :)
> Vit
>
> ruby-sig mailing list
> [e-mail]
> https://admin.fedoraproject.org/mailman/listinfo/ruby-sig

[Bohuslav Kabrda]

Just BTW, I have also added the changed rubygems.spec and rubygem-json.spec and their patches/etc to the "jruby.spec" repo at github [1], so that everyone can browse the changes easily.

[1] https://github.com/bkabrda/jruby.spec

----- Original Message -----
> Hi folks,
> I'm writing a quick summary of what I managed to achieve with
> JRuby/Fedora implementation so far. You can try out my repo at [1]
> and see the progress of work on jruby.spec at [2].
> I have managed to remove the RubyGems copy from JRuby and make them
>
> work with our system RubyGems - I had to apply few JRuby specific
> patches there - two are already accepted upstream, but not merged
> into the 1.8 tree, one is still pending [3]. The updated RubyGems
> are also in the mentioned repo and please be careful when installing
> them, preferably use mock.*
> As a part of the RubyGems modifications, I have also prepared a
>
> sample gem (rubygem-json, also in the repository), with a
> rubygem-json-java subpackage, that provides Java extensions for
> JRuby.
> Pure Gems from Fedora now work with JRuby out of the box, no
>
> modification needed.
> "jgem" command works exactly as "gem", only using JRuby - nice,
>
> isn't it? :)
> load paths set has been brought much closer to MRI, which allowed
>
> most of the stuff I have done
>
> TODO:
> I'm still unsure what is the best way to set up the
>
> Provides/Requires, so that RubyGems would be installable without
> MRI, only with JRuby. I guess we can live with JRuby dragging in
> Ruby, that's a small problem for now :)
> Some modifications to Guidelines will be needed, explaining how to
>
> build Gems/non-Gems for JRuby.
> I will also add a jruby-devel package with macros.jruby to match
>
> MRI's behaviour closely.
> The reason for this is, that I have also tried to introduce new
>
> naming scheme for Gems extensions dirs, which is not compatible with
> the current one. So far, the %gem_extdir was
> "/usr/lib[64]/gems/exts". With Rubinius and JRuby comming, there is
> a slight problem - extensions for JRuby should of course go under
> /usr/share/gems/exts, but Rubinius extensions would have problems,
> as they should go under %gem_extdir, too. Therefore, I'd like to
> propose this scheme for extension placement:
> %gem_extdir %{_libdir}/gems/ruby # MRI
> %xgem_extdir %{_libdir}/gems/rubinius # Rubinius, not sure if that
> should be named "xgem_extdir", what do the others think?
> %jgem_extdir %{_datadir}/gems/jruby #JRuby # JRuby
> This logic to implement this is very simple and it all goes to
> defaults/operating_system.rb in the updated rubygems package in my
> repo (specfile is a bit adjusted, too).
> There is also a question of versioning these dirs, mainly Rubinius
> exts, but I'm leaving that for future, comment if you have any good
> ideas :)
>
> Thanks goes to Charles Nutter for taking the JRuby RubyGems close to
> upstream, which was very important from Fedora integration POV :)
>
> Slavek.
>
> --
> Regards,
> Bohuslav "Slavek" Kabrda.
>
> [1] http://bkabrda.fedorapeople.org/jruby/jruby.repo
> [2] https://github.com/bkabrda/jruby.spec
> [3] https://github.com/rubygems/rubygems/pull/371
> _______________________________________________
> ruby-sig mailing list
> [e-mail]
> https://admin.fedoraproject.org/mailman/listinfo/ruby-sig