The precarious state of jruby in Gentoo

tl;dr jruby in Gentoo will have to go unless we get volunteers to help us with the jruby 1.7 series.

jruby has been available in Gentoo since 2004 and is currently at version 1.6.8. People following jruby will realize that this is a problem: the latest upstream version is 1.7.12 as of this writing. The 1.6 series is also based on ruby 1.8.7 by default. This is a problem since we have removed ruby 1.8 from the tree altogether, and support for it in ruby packages is disappearing fast. jruby 1.6 has a 1.9 mode, but that is based on ruby 1.9.2 where most packages expect at least 1.9.3. We are currently experimenting with defaulting to 1.9.2 mode to extend the 1.6 series. In short, more and more packages that currently have jruby target will loose it on updates since it simply is no longer compatible with jruby 1.7 and in its current state jruby in Gentoo is ready for a slow and agonizing descent. Or we could just be quick about it and mask it soon.

Why not just update to jruby 1.7, you might wonder? We have bug 442230 to track this update, but unfortunately it turns out that it is not easy to add the 1.7 series of jruby to Gentoo. The biggest stumbling block here is that the 1.7 build system is based on Maven. Using Maven is not well supported in Gentoo, mostly because Maven requires the ability to download code during its build phase and does not play very nice with Gentoo's package structure in general. It may be possible to fix this, but that requires good knowledge of Java and Ruby on Gentoo. Currently we don't have any developers capable of both, and passing the code back and forth isn't very practical and proves to go very slow in practice.

So we are looking for a volunteer who wants to pick up this project, and help us bring the jruby 1.7 series to Gentoo. If you see this as a step to become a Gentoo developer than that's great and we can mentor you. If you see this as an interesting one-off project to help out with, that's great too. Once 1.7 is in the tree it should not be a big deal to keep up with new versions. Feel free to drop by in #gentoo-ruby to discuss this with us if you are interested. Our ruby overlay holds the current work-in-progress on jruby 1.7.

If no-one volunteers, unless a magical break-through suddenly appears, we will most likely be forced to mask jruby and remove it from the tree. Help us to not do that!

Published on 23/04/2014 at 17h13 by Hans de Graaff, tags , , , ,

  • by Chewi 30/04/2014 at 12h19

    Hmm, I feel that this post was inadvertently directed at me. I have always been close to the gentoo-java team, despite not having done any solid Java development since 2005, and I kicked the JRuby ebuild into shape for 1.2. I am a full time Ruby developer now so I am probably better positioned to do this than anybody. However, my time is scarce and even though I have experimented with JRuby since, I don't actively use it. I also do practically no Ruby development on Gentoo any more because my employer uses other distros. Even when I do, I use RVM because I find relying on Portage for Ruby development to be impractical. I now accept that Gentoo should not strive to meet this impossibly high target, not least because other distributions with more manpower don't go this far either. Instead it should simply ensure that the handful of Ruby applications in the tree work reliably and are kept up to date. If I were to take up this task, I would not pick up the work previously done on Maven integration. It's way more than I can deal with right now. I would probably not even do the Maven -> Ant conversion that some of the developers seem to prefer. I tend to use java-pkg-simple as I find relying on Maven build scripts to be a false economy, especially since java-pkg-simple ebuilds are usually very short. JRuby is more complex than most packages though so I'd need to evaluate the two approaches. So... let me sleep on it.
  • by Donnie Berkholz 29/04/2014 at 18h01

    Worth noting the GSoC project to add Maven support to Gentoo, which made quite respectable progress a couple of years back and would be worth picking up.
  • by Flow 29/04/2014 at 08h15

    As the previous comment mentioned, the bigger issue is that portage does not support maven very well. Which is sad, because more and more projects start using it, especially with the increasing popularity of gradle (which can be thought of as "being build on top of maven"). I don't even think that a mapping is required. What's really needed is that portage installs maven artifacts of ebuilds to a local, but system global, maven repository. While this sounds easy at first I'm not sure how easy it will be to implement. But I would definitely be willing to help.
  • by Anonymous 28/04/2014 at 23h21

    Sounds like a good reason to get a nice integration between Maven and Portage set up. A dictionary between maven groupid:artifactid:version:classifier and ebuild category/name-version might be needed, but otherwise they are very similar systems. It should be as simple as an eclass to call Maven plugins and goals from ebuild functions.

comment The precarious state of jruby in Gentoo

Trackbacks are disabled

Powered by Publify | Photo Startup stock photos