RubyGems proxy for JRuby missing major use case

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

RubyGems proxy for JRuby missing major use case

mojavelinux
Administrator
It seems to me that the RubyGems proxy for JRuby {1} is missing a major use case (which could perhaps become an key opportunity for Bintray). I'll describe the issue here.

While it's nice that the proxy serves gems so that they can be consumed (i.e., retrieved) by Maven or Gradle, a packaged gem is _useless_ to JRuby. If you try to stick a regular gem on the classpath, JRuby just won't know what to do with it. JRuby _only_ understands how to read a gem in its extracted layout.

You get the extracted gem layout by running `gem install`. The resulting layout format looks like this:

gems/
  asciidoctor-1.5.0/
    lib/
      asciidoctor.rb
      asciidoctor/
        ...
specifications/
  asciidoctor-1.5.0.gemspec

No repository that I know of serves gems this way. Why? As a consequence, the application using the gem inside JRuby has to deal with all the grunt work of downloading the gem, installing it, bundling the extracted layout as a jar and adding the jar the classpath. In other words, we're shifting the onus of packaging onto the developer instead of the repository maintainer. This seems completely ridiculous to me. As far as the developer using JRuby is concerned, a gem should just be another jar file available in a binary (Maven) repository.

I see this as a great opportunity for binary repositories like Bintray. They can implement a repository transformer that takes the gem from rubygems.org, installs it (using these great plugins that we're making all the developers learn how to use {2}), bundles the extracted layout into a jar and serves the result as type = jar instead of type = rubygem.

If we had such a service, then requiring Asciidoctor Diagram in AsciidoctorJ would be a matter of adding the following dependency (shown in shorthand syntax) and you would literally be done!

rubygems:asciidoctor-diagram:1.2.0:jar

This would also allow us to take gems out of the AsciidoctorJ jar and just depend on them as transitive dependencies (that can be excluded if necessary).

To conclude, we should *not* be making users worry about installing and repackaging gems just to load them into JRuby. The repositories should be serving them gems this way! I'm I wrong?

Reply | Threaded
Open this post in threaded view
|

Re: RubyGems proxy for JRuby missing major use case

ysb33r
It would make life a lot easier.

Even better if it can be done at source, meaning that rubygems make both versions available (gem+jar), so that the proxy services don't have to do the conversion.
Reply | Threaded
Open this post in threaded view
|

Re: RubyGems proxy for JRuby missing major use case

mojavelinux
Administrator

I agree, though I don't have high hopes of getting anyone to change rubygems.org. since JRuby is already using a proxy, and it's only relevant for JRuby, I don't see any downside of just doing it there.

One thing is for sure. If we can get both formats, we are going to save ourselves a lot of time & energy.

-Dan

On Aug 26, 2014 5:18 AM, "ysb33r [via Asciidoctor :: Discussion]" <[hidden email]> wrote:
It would make life a lot easier.

Even better if it can be done at source, meaning that rubygems make both versions available (gem+jar), so that the proxy services don't have to do the conversion.


If you reply to this email, your message will be added to the discussion below:
http://discuss.asciidoctor.org/RubyGems-proxy-for-JRuby-missing-major-use-case-tp2075p2076.html
To start a new topic under Asciidoctor :: Discussion, email [hidden email]
To unsubscribe from Asciidoctor :: Discussion, click here.
NAML
Reply | Threaded
Open this post in threaded view
|

Re: RubyGems proxy for JRuby missing major use case

asotobu
Totally agree, from the point of view of AsciidoctorJ users they will be able to exclude and add gems as any single jar.